Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Informatique musicale
Agrandir
Informatique musicale
Instruments et matériels audio
Informatique musicale
Produits 30 404 30,4k
Actu 30 713 30,7k
Articles 1 747 1,7k
Médias 320 005 320k
Tutoriels Tutos 1 790 1,8k
Avis 23 421 23,4k
Petites annonces Annonces 2 252 2,3k
Forums 141 968 142k

Sujet Tordre le cou au moteur audio:

  • 212 réponses
  • 40 participants
  • 28 972 vues
  • 56 followers
Sujet de la discussion Tordre le cou au moteur audio:
Ok, je vais essayer de mettre dans ce thread un petit recapitulatif d'avis t d'infos récupérés a droite a gauche sur le net, afin de ruiner le vieux mythe du moteur audio. merci de ne pas poster de commentaires et de ne pas entamer de fumeux debats sans arguments ici.
pour ça, un autre thread:
Tordre le coup au moteur audio: polemiques et crtiques
Afficher le sujet de la discussion
101
Citation de Dr :
Non mais il faut dire que Alex.d et moi, on a philosophé sur une question théorique assez simple : « peut-on paralléliser (= découper en petits bouts et mettre dans des threads, pouvant être répartis sur différents cœurs) n’importe quel petit morceau de logiciel ? ».

Et comme il n'y a pas encore d'API pour des plugins audio multithreades et pouyr eviter des pools de threads dans chaque plugin qui vienne mettre a genou une machine, un plugin devrait toujours etre mono thread. Un instrument standalone n'a pas cette contrainte.
C'est logique, non ?

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

102
Citation de Dr :
icon_facepalm.gif
Miles, un peu de tact, que diable ! :-D

En plus on s’est expliqué et fait des bisous dans les messages après celui que tu cites !

Allez, peace :boire: :bravo:

Faut dire que j'en ai eu un du meme tonneau au bureau, ou presque...

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

103
Salut les geeks !
Je me permets juste une petite remarque bien que totalement étranger au monde de la programmation et absolument nul en maths depuis la 5ème :8)
Quand j'ai lu le problème d'Hakim avec Kontakt et les grosses librairies de samples associées dans le topic de Logic j'ai immédiatement voulu faire une remarque mais étant d'une part incompétent dans le domaine et en plus n'adhérant pas à la secte de la pomme j'ai préféré me taire. Or il semble (à la lecture diagonalisée des dernières pages) qu'elle eut été tout à fait pertinente : plutôt que de pester contre la (à priori mauvaise mais finalement non si j'ai bien compris) gestion des différents cœurs par Logic, pourquoi diable personne n'ose élever la voix contre un plug qui met à genoux des machines aussi chères et performantes que celles dont il est question et que bien peu d'home-studistes amateurs peuvent d'offrir ?
Depuis que ces types d'instruments virtuels existent (librairies multisamples dont la taille se compte en Go) je constate qu'elles entrainent un problème aux nombreuses ramifications et pas des moindres : la puissance du CPU (vitesse et nombre de cœurs), la RAM, l'architecture de la machine et de l'OS et enfin le codage des logiciels pour exploiter au mieux les possibilités hardwares disponibles. Je me demande moi comment on peut faire tourner un orchestre symphonique au grand complet en plus des autres traitements habituels (EQ, compresseurs, réverbes etc.) J'ai comme l'impression qu'il faudrait quasiment une ou plusieurs machines dédiées à Kontakt pour les instruments virtuels en plus de la workstation.
Bref veuillez pardonner mon ignorance et mon manque d'expérience en la matière mais moi je ne me vois pas utiliser des banques Kontakt aussi gourmandes en ressources sachant qu'Hakim possède du matériel performant très onéreux... C'est un peu comme si un éditeur sortait un jeu vidéo qui ne pourrait pas fonctionner correctement car la plateforme (console ou ordi) serait sollicitée à 150%. Vous voyez ce que je veux dire ? On marche un peu sur la tête là non ?

Putain Walter mais qu'est-ce que le Vietnam vient foutre là-dedans ?

[ Dernière édition du message le 24/04/2018 à 17:30:48 ]

104
Citation :
C'est un peu comme si un éditeur sortait un jeu vidéo qui ne pourrait pas fonctionner correctement car la plateforme (console ou ordi) serait sollicitée à 150%. Vous voyez ce que je veux dire ? On marche un peu sur la tête là non ?

Les machines étant toujours plus puissantes on fait des logiciels toujours plus sophistiqués, qui nécessitent des machines encore plus puissantes, etc...

Citation :
Et comme il n'y a pas encore d'API pour des plugins audio multithreades et pouyr eviter des pools de threads dans chaque plugin qui vienne mettre a genou une machine, un plugin devrait toujours etre mono thread. Un instrument standalone n'a pas cette contrainte.
C'est logique, non ?

Ben je ne sais pas. Vu que ça marche en bridge, j’ai l’impression qu’il vaudrait mieux que Kontakt ait ses propres threads, et que Logic n’en entrave pas le fonctionnement.
Et puis je voyais hier que sur ma machine où il n’y avait pas beaucoup de logiciels qui tournaient, il y avait 1300 threads. Alors 10 ou 20 de plus, par instrument qui en a vraiment besoin, est-ce aberrant ?

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

105
1300 threads, c'est juste...
Disons que ces threads doivent avoir une priorite plus importante et s'ils sont trop nombreux pour le nombre de coeurs (typioquement, il faudrait un mapping 1 pour 1), il va y avoir plus de switchs que requis et quand la machine atteint sa limite, alors encore plus rapidement les switchs vont pose problemes.
Et encore une fois, c'est un probleme classique dans le domaine HPC ou pour maximiser la perf d'une machine, on met le nombre de thread qu'il faut et on les pinne en plus a un coeur pour eviter tout probleme d'allocation memoire ou de transfert de cache inutile.
Bref, on est tres loin de faire les choses correctement, et ne pas partager une thread pool fait partie de ces problemes (resolus depuis longtemps pour MKL pour ne parler que de cette bibliotheque de calcul).

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

106
Bien entendu, tu ne vas pas donner la main à chacun des 1300 threads (ou 2097 à l'instant, sur mon PC) sur le chemin critique. Les threads audio utilisent un ordonnancement temps-réel ; tout ce qui est interface graphique, I/O disque, etc., est dans d'autres threads. Sous Linux, on utilise la classe SCHED_FIFO qui est ordonnançable avant n'importe quel thread normal (SCHED_OTHER) et n'est jamais préempté. Ça garantit que tant qu'un thread audio a du travail, il aura la main sauf si un autre thread de même classe est exécuté sur le même core. Il peut y avoir quelques changements de contextes sur le chemin. jackd fait ça tout le temps, et ça se passe bien (là encore, grâce à l'ordonnancement temps-réel).

Bien sûr, il y a de petits surcoûts, mais de toute façon il est illusoire de vouloir optimiser pour le cache et la localité quand on travaille sur de si petits buffers. En audio, le contexte est un peu différent du HPC. Si tu as tes buffers à 256, en stéréo 32 bits, ça fait un tableau de 2KB, c'est tout. On est loin des problématiques de la MKL !

En revanche, l'équilibrage de charge est plus délicat, parce qu'on ne maîtrise pas les calculs qui sont dans les plugins qui sont des sortes de boîtes noires vu de l'hôte. Non seulement il y a les dépendances de données, mais en plus certains plugins coûtent peanuts quand d'autres vont être très lourds, et ça l'hôte ne peut pas le savoir. Du coup, placement et ordonnancement seront au mieux des heuristiques, mais tout ça reste empirique.
107
je post pour flag et aussi pour vous remercier de tous ces messages et sources, j'ai passé un bon moment à tout lire :-)
108
Citation de Dr :
Les machines étant toujours plus puissantes on fait des logiciels toujours plus sophistiqués, qui nécessitent des machines encore plus puissantes, etc...


Et alors ça justifie de mettre la charrue avant les bœufs ? Je parle de logiciels qui sortent avant que les machines soient suffisamment puissantes pour les faire tourner. Tiens ça me rappelle Vista, ça ramait même sur un ordinateur neuf icon_facepalm.gif

Putain Walter mais qu'est-ce que le Vietnam vient foutre là-dedans ?

109
Ils avaient juste un peu d’avance dans leur planning, ce qui normalement n’arrive jamais. :oops2:

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

110
1. Voici la première question, le 1er post de cette discussion que j'ai initiée, pour ceux qui se sont égarés :
Citation :
Quand le problème de la surcharge d'un seul cœur lorsqu'on joue une piste live avec un gros IV sera résolu ? Ex : Je mets un Kontakt avec une grosse librairie sur une piste, je joue et bing j'ai un cœur qui monte au taquet (avec les grésillements et tout qui vont bien) alors que les 23 autres cœurs restent peinards à moins de 1%. P**ain, j'ai acheté un Mac pro "poubelle" 12 cœurs pour ça! Mon ancien Hackintosh faisait beaucoup mieux, forcement je n'avais que 4 cœurs mais chacun allait à 3.5GHz. Sur le mac pro, un cœur va 2.7GHz.

Je me plains donc d'un problème existant depuis le début de la MAO et des multi-cœurs. Je suis surpris qu'en 2018 les développeurs de Logic n'aient pas trouvé une parade.
2. Sur ce, vous m'expliquez que c'est impossible, il faut faire un calcul après l'autre car ils sont interdépendants pour le jeu en temps réel, on ne peut pas les répartir sur les cœurs. C'est impossible et ça le sera toujours. (Répété plusieurs fois). Vous êtes sûr que c'est impossible hein, car vous connaissez tout, vous avez tout vu.
3. Tiens mais voilà que lorsqu'on met Kontakt dans un bridge et qu'on pilote le tout depuis Logic, le travail dans Logic (via les jauges de Logic) semble être mieux réparti sur les cœurs, je ne sature plus un cœur quand je joue une piste. N'est-ce pas une solution réalisée par programmation? Pourquoi un bridge est capable d'utiliser plusieurs cœurs dans ce cas précis et pas Logic? Donc ce n'est pas impossible, les spécialistes ici se seraient-ils trompés?
4. Mais lorsque j'ai dit ça, plutôt que de le reconnaitre, les nuances sont arrivées :
Citation :
Non mais il faut dire que Alex.d et moi, on a philosophé sur une question théorique assez simple : « peut-on paralléliser.
Euh non Alex.d n'était pas là au début, c'était darkmoon. J'ai soumis un problème de surcharge single-core dans un cas très pratique et vous avez dit qu'il est insoluble (rappeler vous 2+2, y=f(g(x))).
Citation :
On a essayé d’expliquer pourquoi ce n’est pas toujours possible...
Nuance aussi, vous avez expliqué pourquoi ce n'est JAMAIS possible.
Citation :
Là vu que ça marche en bridge, ça laisse penser qu’il y a encore des trucs pas bien optimisés dans Logic.
Tiens donc n'est-ce pas ce que je supposais au tout début? C'était bien la peine toute cette prose entre-temps.
Citation :
Si oui, il semble que le problème et les limitations soient du côté de Logic. Déjà le fait que Logic soit incompatible avec le multicore de Kontakt, ça ne me semble pas génial quand même.
Et voilà le final, ce dont je me plaignais dans mon 1er post, retour au point de départ, Logic peut mieux faire, bravo! Et j'ai du coup l'impression que les personnes qui m'ont répondu n'utilisent pas quotidiennement Logic et Kontakt.
5. Et là-dessus vient un énergumène (miles1981) qui n'a pas suivi le déroulement et qui m'insulte en extrayant un seul message de son contexte :
Citation :
J'ai rarement vu autant de conneries en un seul post. Bravo. Tu n'as rien compris au traitement du signal, a l'IA ou même a la programmation.
Je conçois des automatismes et des stations de supervision combinant traitements et mise en forme de tout type de signaux depuis 30 ans, j'espère que mon boss ne lit pas le forum AF. D'abord si tu avais bien suivi tu aurais compris que ce message-là n'était que pures spéculations pour répondre au "c'est impossible", faut peut-être tout lire avant d'agresser, la discussion ayant commencée sur le forum du test de Logic 10.4. Toi qui as tout compris en programmation, explique-moi donc pourquoi au final, j'ai raison? Mon intuition était bonne, Il y a bien moyen de contourner le problème par programmation puisque qu'avec VEPro je n'ai plus le cœur qui sature dans exactement les mêmes conditions. Comment ils codent chez VSL? Toi et ton immense connaissance de la programmation, vous semblez n'avoir su que venir foutre la merde. (J'en ai aussi des comme ça, au boulot, incapable d'avoir une seule idée, seulement capable de ridiculiser les idées des autres).
Sur Gearslulz, un gars raconte comment il verrait un outil de type VEPro intégré en natif dans Logic (genre le remplaçant du node de Logic 9 en mieux), mais bon, vu que vous êtes sûr que c'est impossible, je suppose qu'il n'a rien compris à la programmation, ça doit être un con.
Une quarantaine de posts sans aucune réponse à ma question pour que je me fasse insulter au passage. Je pense qu'on ne m'y reprendra plus, je laisse les spécialistes entre eux. De toute façon ça n'a servi à rien.
6. En pratique maintenant je cherche une alternative à VEPro. VEPro est surtout destiné à la mise en réseau de plusieurs ordinateurs pour faire tourner les grosses librairies sur des ordinateurs esclaves. Je n'ai pas besoin de ça et je ne peux pas sortir 280€ pour l'acheter. J'ai juste besoin d'un bridge qui tourne sur le même ordinateur que Logic. Je n'ai trouvé que des équivalents pour PC.

 https://soundcloud.com/hakim-fr

https://www.youtube.com/user/Hakim2M/videos

https://soundcloud.com/user-527271038

[ Dernière édition du message le 25/04/2018 à 10:05:21 ]