Tordre le cou au moteur audio:
- 212 réponses
- 40 participants
- 30 647 vues
- 56 followers

Anonyme

pour ça, un autre thread:
Tordre le coup au moteur audio: polemiques et crtiques

miles1981

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.
Audio Toolkit: http://www.audio-tk.com/

Hakim+K


Hakim+K

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 ]

miles1981

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).
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).
Audio Toolkit: http://www.audio-tk.com/

miles1981

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é.
Audio Toolkit: http://www.audio-tk.com/

Dr Pouet

ê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.

Ça ne me semble viable que quand une seule appli, ou uniquement des applis prévues d’avance, vont tourner sur la machine.

Hakim+K

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,
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
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
[ Dernière édition du message le 25/04/2018 à 21:08:31 ]

Darkmoon

...j'ai dit exactement que ça met en doute ça :Citation :Un truc que tu disais impossible est devenu possible.C’est tout simplement impossible techniquement~physiquement à cause de l'implication du/de la notion de temps réel.
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

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 ]

Dr Pouet

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 » ?

Dr Pouet

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 ]

Hakim+K

avec le binding des threads de Logic qui est vraisemblablement hérité par les threads de Kontakt qui sont alors attaché à un seul coeur.
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 ]

Darkmoon

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?

"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

Hakim+K

ce qui cloche entre Logic et Kontakt, puisque ça marche mieux avec d'autres STAN et ça marche mieux avec un bridge

Danbei

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.

miles1981

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?
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.
Audio Toolkit: http://www.audio-tk.com/
[ Dernière édition du message le 25/04/2018 à 22:24:08 ]

miles1981

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.
Audio Toolkit: http://www.audio-tk.com/

Jimbass

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.
Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts

alex.d.

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.

antart

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!

Darkmoon


"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

Darkmoon

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.

"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

Hakim+K

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 ]

Darkmoon

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 !!!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 ]

Elka21


Hakim+K

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 ]
- < Liste des sujets
- Charte