(05-20-2020, 09:11 AM)audyart a écrit :(05-19-2020, 10:13 PM)Nard a écrit : Les quelques centaines de milliers de taps qui précèdent l'impulse peuvent être traités en une fraction de seconde.
La préconvolution est ainsi traitée en quelques millisecondes au lieu de n secondes et placée dans le buffer de sortie (dans le parfait respect du principe du FIR).
La lecture du flux audio convolué peut ainsi commencer avec seulement quelques ms de retard. Elle a alors lieu à vitesse normale.
Donc, résumé, avec une impulsion de "quelques centaines de milliers de taps" la sortie convoluée
"commence avec seulement quelques ms de retard"
c'est cool les miracles, mais:
(131072 taps en 48 kHz )
délai de principe = 131072 / ( 48*2) = 1,365 secondes
C'est quoi une convolution ? Une opération matricielle qui consiste à multiplier une fenêtre glissante du flux audio par une impulsion.
Quand on écoute un flux convolué, cette opération est faite au fur et à mesure de sa lecture, à la vitesse du flux ie. 44,1 96 ou 192kHz. Il se produit donc une latence au démarrage liée au traitement du flux audio. Si l'impulsion dure deux secondes, il y a une seconde d'attente liée au pre-traitement (nécessité du Fir de travailler en amont de l'instant traité).
Rien n'impose que ce pré-traitement soit effectué à la vitesse du flux audio. S'il est effectué à la vitesse du processeur, il ne faut que quelques millisecondes pour multiplier une seconde de flux audio par un fichier d'impulsion. Le produit résultant est un flux audio convolué d'une seconde auquel il ne restera plus qu'à appliquer, en temps réel cette fois, le reste de l'opération matricielle avec la seconde moitié de l'impulsion, le flux pourra alors être lu sans plus attendre.
Il n'y a pas de miracle là-dedans.
On peut être une référence en audio et tout à la fois une quiche en informatique et c'est tellement drôle d'être pris pour un zozo

Pluie du matin n'arrête pas le sous-marin