Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

Tordre le cou au moteur audio:

  • 212 réponses
  • 40 participants
  • 30 647 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
151
Citation de Hakim+K :
C'est fou quand je disais ça au début, on m'a assassiné de théorie pour m'expliquer que Logic et Kontakt fonctionnent normalement et que c'est les principes de base qui conduisent au problème de surcharge single-core en live et qu'il n'y a rien à faire. Mais là maintenant c'est acquis que Logic et Kontakt ont un problème avec le multithreading. Bravo la théorie! Tu ne dirais pas ça sans les expérimentations que j'ai partagé.

Non, Logic et Kontakt n'ont aucun problème, c'est Kontakt qui ne fait pas son travail correctement (être multithreadé et ne pas détecter le binding).
Et Logic fait son travail correctement, à savoir binder les coeurs.
152
ça semble être parti sur une vraie discussions enfin avec des hypothèses sérieuses plutôt que des "c'est comme ça" et "c'est impossible", tiens donc?
153
Euh tu dis Logic et Kontakt n'ont aucun problème puis juste après Kontakt ne fait pas son travail correctement, ce n'est pas un problème de Kontakt s'il ne fait pas son travail? Parce que moi quand je ne fais pas mon travail correctement c'est mon problème.
Après en Standalone le multithreads de Kontakt fonctionne, pas de surcharge avec les mêmes instru.

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

154
Citation de Dr :
Parce que les threads de Kontakt sont en compétition avec ceux de Logic pour les mêmes ressources.

Sauf que les threads de Logic se tournent les pouces. Si on part du principe qu’un instrument se crée des threads quand ça se justifie, hypothèse plutôt raisonnable, il n’y a pas de raison de l’en empêcher. [/quote]
Effectivement, c'est alex.d qui a donné la solution avec le binding des threads de Logic qui est vraisemblablement hérité par les threads de Kontakt qui sont alors attaché à un seul coeur. C'est pourtant la bonne pratique, ce que fait Logic. En revanche, Kontakt ne devrait créer que des threads pour remplir le binding qu'il crée (c'est facile à calculer).
Citation de Dr :
Peux-tu préciser cette notion de spin ? Je ne suis pas sûr de connaître.

Quand les threads ne font rien, ils peuvent rendre la dispo à l'OS, ou alors être en spin wait (grosso modo while(true){}). Ce dernier évite un délai de réveil (parfois), et sur les clusters où les threads sont bindés, c'est la pratique usuelle (parce que rien d'autre n'est plus important et les codeurs développent leur application pour avoir 1thread = 1 coeur car c'est là que tu maximises la perf).
155
Citation de Hakim+K :
Euh tu dis Logic et Kontakt n'ont aucun problème puis juste après Kontakt ne fait pas son travail, ce n'est pas un problème de Kontakt s'il ne fait pas son travail? Parce que moi quand je ne fais pas mon travail correctement c'est mon problème.

Tu dis que c'est un problème de Logic et Kontakt, non.
Et le problème original du séquencement des opérations est un vrai problème que tu n'as pas encore compris, je maintiens la position. En revanche, à force de te tirer les vers du nez, on a réussi à comprendre le véritable problème que tu as rencontré. f(g(x)) ne pourra jamais être parallélisé.
156
Citation :
être en spin wait (grosso modo while(true){})

Ah oui, pour moi ça s’appelait de « l’attente active ».

On peut soit gagner un peu, soit perdre beaucoup avec ce genre de stratégie. :-D
Ça ne me semble viable que quand une seule appli, ou uniquement des applis prévues d’avance, vont tourner sur la machine.
157
Citation :
Et le problème original du séquencement des opérations est un vrai problème que tu n'as pas encore compris

Si si compris depuis au moins 6 ans,
Citation :
En revanche, à force de te tirer les vers du nez, on a réussi à comprendre le véritable problème que tu as rencontré. f(g(x)) ne pourra jamais être parallélisé.

Par pitié, on s'en fout, on cherche ce qui cloche entre Logic et Kontakt, puisque ça marche mieux avec d'autres STAN et ça marche mieux avec un bridge. Explique-moi plutôt cette phrase
Citation :
Effectivement, c'est alex.d qui a donné la solution avec le binding des threads de Logic qui est vraisemblablement hérité par les threads de Kontakt qui sont alors attaché à un seul coeur. C'est pourtant la bonne pratique, ce que fait Logic
. Il y a une contradiction non?

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

158
Citation de Hakim+K :
...j'ai dit exactement que ça met en doute ça :
Citation :
C’est tout simplement impossible techniquement~physiquement à cause de l'implication du/de la notion de temps réel.
Un truc que tu disais impossible est devenu possible.


Lequel? Tu nous le rappelles SVP. Car si je me relis, je constate juste que j'ai dit que c'est impossible de calculer simultanément des opérations qui doivent attendre d'autres résultats. Alors de quoi tu causes? Cite-moi le passage exact ;)

Citation de Hakim+K :
C'est fou quand je disais ça au début, on m'a assassiné de théorie pour m'expliquer que Logic et Kontakt fonctionnent normalement...


Pas du tout, j'ai évoquer une possibilité (tu connais le concept/notion de ce mot?) mais n'ais rien affirmé au départ. Tu fais des épouvantails parce que tu ne veux tjrs pas comprendre que je partageais des généralités et que ça pouvait servir à d'autres. Et que j'ai argumenté, te concernant, uniquement après que tu à commencer à prétendre que nous disions tous n'importe quoi. T'es trop centré sur toi-même et tu t'offusque trop rapidement. Désolé.

"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou

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

159
Citation :
Effectivement, c'est alex.d qui a donné la solution avec le binding des threads de Logic qui est vraisemblablement hérité par les threads de Kontakt qui sont alors attaché à un seul coeur. C'est pourtant la bonne pratique, ce que fait Logic. En revanche, Kontakt ne devrait créer que des threads pour remplir le binding qu'il crée (c'est facile à calculer).

Kontakt pourrait créer des threads qui ne seraient plus liés au cœur qui héberge le thread de la tranche de Logic ?

Une sorte de « vraie option muliticore » ?
160
Citation :
Et Logic fait son travail correctement, à savoir binder les coeurs.

C’est pour ne pas casser le pipeline au sein d’un cœur ? (Et optimiser ainsi la puissance de calcul)

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

161
Citation :
avec le binding des threads de Logic qui est vraisemblablement hérité par les threads de Kontakt qui sont alors attaché à un seul coeur.
Comprends toujours pas ça, surtout qu'il est recommandé par NI et Apple (j'ai déjà posté les liens) de mettre l'option multicore de Kontakt sur off (en mode plugin bien sûr) et tous le monde le fait depuis longtemps (pas que moi hein).

Citation :
Kontakt pourrait créer des threads qui ne seraient plus liés au cœur qui héberge le thread de la tranche de Logic ?

Je ne vois pas trop comment, ça revient à sortir de soi-même, mais rien n'est impossible.

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

162
Question pour miles1981/alex.d.

Si Logic fait son boulot et que ça provient de Kontakt, qu’est-ce qui explique que ce dernier fonctionne sans problème dans certains autres DAW? N’y a-t-il pas, forcément, une implication/relation entre le DAW/Kontakt puisque ce dernier pose prob dans Logic, mais pas dans d’autres DAW?

:noidea:

"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou

163
Déjà demandé post 157
Citation :
ce qui cloche entre Logic et Kontakt, puisque ça marche mieux avec d'autres STAN et ça marche mieux avec un bridge
164
Citation de darkmoon :
ce dernier pose prob dans Logic, mais pas dans d’autres DAW?

Est ce qu'on est sur de ça ? J'ai peut être raté quelque chose dans la discussion, mais si j'ai bien compris :
-Hakim tu as testé dans Logic et en standalone mais pas avec d'autre DAW.
-Et toi Darkmoon tu as tester dans Studio One et FL studio mais pas dans Logic.
Vos config sont sans doute différentes donc on ne peut pas conclure que ça marche moins bien dans Logic que les autres DAW.
Mon hypothèse c'est que tout les DAW on a peu près le même problème.
165
Citation de darkmoon :
Question pour miles1981/alex.d.

Si Logic fait son boulot et que ça provient de Kontakt, qu’est-ce qui explique que ce dernier fonctionne sans problème dans certains autres DAW? N’y a-t-il pas, forcément, une implication/relation entre le DAW/Kontakt puisque ce dernier pose prob dans Logic, mais pas dans d’autres DAW?

:noidea:

Parce que les autres STANs ne font pas de binding des threads ?

DrPouet > oui, c'est mieux quand un thread haute priorité est bindé à un coeur de sorte que les données de ce thread ne bougent pas et qu'un autre thread haute priorité ne lui pique pas du temps.

[ Dernière édition du message le 25/04/2018 à 22:24:08 ]

166
Citation de Dr :
Kontakt pourrait créer des threads qui ne seraient plus liés au cœur qui héberge le thread de la tranche de Logic ?

Une sorte de « vraie option muliticore » ?

Oui, mais c'est pas recommandé.
Encore une fois, la seule option légitime est un thread pool de threads haute priorité qui serait fourni par la STAN.
167
Il y a aussi un souci courant mais méconnu quand on fait du temps-réel sur multicœur : l'accès simultané aux ressources partagées. Dont la mémoire fait partie, et souvent les caches L2 et/ou L3. Il y a des arbitrages en matériel, qui font qu'un cœur aura la ressource et les autres vont attendre. En moyenne ce n'est pas super grave (et sur de l'audio ca ne fera qu'ajouter un petit jitter) mais pour des applications critiques ca peut être un vrai souci.

Par exemple, un collègue arrivait il y a quelques années, avec du traitement d'image assez optimisé en SSE2 sur deux cœurs, à saturer la bande passante du cache L2 partagé.
Un autre exemple est celui de deux threads, qui en accédant à des tableaux mal rangés au regard de l'associativité du cache, s'évictent mutuellement les données.
Il y a plein de mécanismes comme ca, qui font assez rapidement dégringoler la perfo (ou la font varier de manière imprévisible) quand plusieurs choses se passent en même temps.
168
Citation de miles1981 :
Le souci arrive donc bien si tous les plugins se créent leur propre thread pool avec des threads temps réel (+ spin en général dans le thread pools pour permettre d'avoir une réactivité).


En général, tu ne fais pas d'attente active. Ça peut arriver parfois en HPC (et à condition de ne pas faire du green !), mais ça ne marche que pour une appli qui est seule sur son noeud, pas pour une bibliothèque qui doit partager les cores, et a fortiori pas pour un plugin qui sait par définition qu'il n'est pas seul.

Je ne connais pas les détails sous Windows ou Mac, mais sous Linux, avec jackd il n'y a que de l'attente passive pour passer la main aux threads. Ça se fait avec des write() et poll() (et non un pthread_cond_signal() comme on pourrait l'envisager intuitivement) parce que sur l'ensemble des systèmes supportés, c'est l'appel qui garantit que c'est précisément le thread temps-réel qui sera réveillé dès qu'il sera prêt. De mémoire, il me semble qu'on a aussi la garantie avec les sémaphores, mais pas sur tous les sytèmes.

Bon, après peut-être que sous Mac, il y a de l'attente active dans Logic ou dans Kontakt, mais alors là, tu m'étonnes que ça pète ! Mais je ne pense pas qu'ils soient aussi bêtes, au point de mettre de l'attente active dans un truc dont tu sais qu'il sera composé avec autre chose et donc qu'il ne sera pas tout seul.
169
Citation de darkmoon :
Citation de Papy :
ouais sauf que c'est bien connu que le moteur audio de fl c'est de la m*rde.


J'imagine que c'est une plaisanterie/troll, mais étant donné qu'il gère parfaitement le multithreading avec Kontakt (et de gros patchs/instruments orchestraux que j'utilise), l'on peut, à minima, conclure que FL, ainsi que Studio One avec lequel je n'expérimente aucun problème avec Kontakt, possèdent tous deux un moteur audio n'ayant pas les problèmes de Logic concernant Kontakt et le multithreading!


yes c'etait une petite blague car j'entend et vois souvent beaucoup de monde critiquer FL alors que de mon coté même si ça n'est plus mon DAW principal je l'utilise encore car c'est un monstre plein d'atouts!
170
:bravo:

"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou

171
Juste souligner un point (et, attention Hakim, ça n'a pas forcément rapport avec ton problème puisque sous VEP tu dis être OK. C'est juste une remarque générale pour souligner que certaines banques posent parfois problème) : certaines banques Kontakt sont mieux structurées/scriptée que d'autres et ce n'est pas forcement corrélé à la qualité sonore de la banque. Ça fait des années que je trafique/étudie les banque que j'achète (et je script un peu du KSP moi-même) et j'ai remarqué que certaines banques sont moins bien optimisées/conçus que d'autres.

Par exemple, certaines banques/instruments possèdent jusqu'à 5 layer de dynamique où même la plus soft dyn, le « p », recouvre le « f ou ff » en crossfade, ce qui implique le jeu de sa voix alors que la Modwheel à donf, en ff, ne nécessiterait pas l'exécution de cette voix. Autremendit, le crossfade des layers est utile entre certaines jonctions (p à mp, mp à mf, f à ff), mais le p n'a pas à être joué (même s'il est inaudible parce que crossfadé) quand on joue en ff la modwheel à fond. Et quand l'éditeur fait de même avec les releases trails et les legatos, ben ça fait un instrument qui te consomme parfois plus de 15 voix justes pour une simple et unique note jouée. :??: (Et dès que je joue en note liée assez rapidement, je peux facilement monter à plus de 250 voix pour un seul instrument dans Kontakt.)Tout ça pour dire que c'est un facteur de plus qui affecte les perfs, dépendamment des banques utilisées. Il y a vraiment tout un tas de facteurs (en plus de l'OS, du DAW, etc.) qui ont donc incidence et qui font que certains peuvent éprouver des problèmes que d'autres n'ont pas (sans compter la puissance de la machine, l'utilisation de SSD ou non, etc.).

"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou

172
Oui j'ai remarqué ça aussi, en pratique ça se traduit par certaines banques de Spitfire pourtant chargées qui passent bien alors que toutes les banques Output bouffent un max et bien sûr je diminue la polyphonie pour limiter les dégâts. Et toutes mes banques sont sur SSD, 8To quand même (4x2To en raid0).
Mon intuition va toujours dans le sens ou je pense qu'il doit y avoir moyen d'améliorer ça dans Logic. J'espère secrètement une amélioration pour la version 10.5 ;-).
Et je partage le point de vue du gars qui s'indignait de la lourdeur de Kontakt. Après tout, il n'y a pas de problème avec l'ESX24. Mais bien sûr les banques de l'ESX24 sont très bien optimisées vu qu'elles sont faites par le même développeur alors que les banques Kontakt sont faites par pleins de développeurs différents. Tiens, je pourrais essayer de voir si les banques NI sont mieux optimisées.

[ Dernière édition du message le 26/04/2018 à 08:41:41 ]

173
x
Hors sujet :
Petite digression... ...après plusieurs mois « d'études » de benchs, reviews/tests, je viens de faire mon choix pour mon nouveau PC. Et puisque je n'ai pas changé depuis près de 8 ans (la plus longue période, avant je changeait bcp plus souvent), j'ai mis le paquet (4000$) :

-Asus tuf z370-pro gaming,
-Intel Core i7-8700K (6 core/12 thread, 4.7GHz turbo),
-64GB DDR4 G.SKILL CL15
-2 SSD M.2 en mode NVMe PCIe : un 256Go pour l'OS et un 1To pour mes banques Kontakt.
-Msi geforce gtx 1060 gaming x 6g
-Etc, etc.

À eux seuls, les 64Go de RAM et le 1To Samsung 960 EVO M.2 NVMe PCIe font près de la moitié du prix de la bête!

Par rapport à mes SSD actuels en SATA, je devrais passer d'un bandwidth de +/- 500Mo/s à +/- 2.5Go/s !!! :aime: Je devrais recevoir le tout mardi prochain. J'ai vraiment hâte de voir le gain de temps de chargement concernant certains de mes gros templates chargé à bloc d'instruments Kontakt. Ainsi que ce que je vais gagner en terme de buffer/ms pour un même template (avec la même carte son : Roland Quad-Capture. À Noël prochain, ce sera sans doute le temps de changer pour une RME BFP, juste pour bénéficier de la plus faible latence pour une carte son en USB.).

"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou

[ Dernière édition du message le 26/04/2018 à 09:42:21 ]

174
En 2004 on pouvait déjà jouer en live a très faible latence un piano de plus de 10GO avec 31 vélocité sur un pentium P4 . . . Alors si tout a suivi en proportion (comme on aimerait le penser), les possibilités (devraient) être plus qu'impressionnante . . .
175
x
Hors sujet :
J'envisage aussi le i7-8700K pour ma future machine (dès que j'arrive à vendre mon Mac pro, je me remonte un Hackintosh, c'est quand même plus performant et moins cher). J'hésite néanmoins avec le I7-7820X, 2 cœurs de plus pour une fréquence un poil inférieur (3.6 contre 3.7GHz). Y aussi le I9-7900X qui monte quand même en turbo à 4.5GHz, 10 coeurs des perfs de ouf sur www.cpubenchmark.net, mais trop cher pour l'instant... Tu nous diras comment ça dépote ?...
J'ai aussi monté un Samsung 960 EVO M.2 NVMe dans mon Macpro grâce à un adaptateur et une bidouille (les Mac pro cylindre de 2013 ne sont bien sûr pas compatible Nvme). Le bus pcie n'étant que du 4x, j'atteins maintenant les 1450Mo/s contre 900 avec le disque d'origine, je perçois la différence alors avec 2.5Go/s...
Par contre si je peux me permettre, ayant eu l'octa-capture plus de 4 ans (4 albums), j'ai gagné en buffer/ms en passant sur une carte thunderbolt, pour les raisons que tu connais sans doute (Clarett 8 pre maintenant). Certe la RME BFP a une meilleure latence que l'octa-capture sur le papier mais je doute que ça fasse une réelle différence en pratique. Après question de goût, mais moi je préfère de loin l'ergonomie de l'octa à celle de la Babyface et puis tu vas payer plus cher pour avoir moins d'entrées, avec les 8 préamps de l'Octa tu peux enregistrer un petit groupe. En terme de qualité de son (préamp toussa...), je suis passé de RME Fireface et/ou Apogee Duet à Octa-capture sans entendre la moindre différence de qualité dans mes prises. RME c'est surtout un prestige qui se paye. Et l'octa a quelques petits plus (la fonction autogain, le compresseur tellement discret et efficace que je le laissais à la prise... etc). Bref si on me demandait de choisir entre Octa-capture et RME BFP, je préférerais l'Octa et en plus je ferais des économies. C'était mon petit point de vue avant que t'achètes la BFP.

[ Dernière édition du message le 26/04/2018 à 12:16:44 ]