LinFIR - Mesures et égalisation FIR/IIR

[Dagda]

Pourquoi ne pas mettre la courbe théorique en "fantôme" pour voir la cible à "atteindre" ?
On a ainsi l'approche complète. Ce que fait réellement le filtre et ce que l'on aimerait atteindre. Ainsi, comme dans cet exemple, on voit que pour faire ce filtre il faut augmenter le nombre de Taps et donc bouffer de la ressource ...

C'est une idée ...

D.

[Jean Fourcade]

Je crois que c'est possible avec la notion de cible ("Target") mais peut-être pas avec un crossover.

[Arnwald]

Merci d'avoir corrigé mes propos. Mais si vous saisissez le nombre de taps, vous êtes alors limité dans les filtres que vous pouvez générer comme rePhase y compris sur l'amplitude.

Oui, et c'est une limite mathématique. Mais ce n'était pas "mon point". Le problème que j'ai avec rePhase, c'est que toute l'interface se comporte comme si le nombre de taps était infini avant que l'utilisateur ne clique sur le bouton "Generate".

C'est précisément la différence que vous notez par la suite avec LinFIR. Je trouve au contraire qu'avoir le résultat directement permet d'itérer plus rapidement et facilement en se rendant compte de la limite qu'introduit un nombre de taps donné: quand on fait un clic maintenu sur la valeur de taps et que l'on fait défiler en glissant la souris de gauche à droite, on voit le filtre perdre ou gagner de la résolution dans le grave.

J'ai manipulé le logiciel un petit peu. L'ergonomie m'apparait très bonne

Merci.

Je n'en suis pas forcément super satisfait moi même, mais à un moment donné il faut faire un choix...

[pvrx]

Bonjour à tous,

Je reviens sur mon sujet de l'importation dans LinFIR de mesures effectuées avec d'autres outils, en l'occurrence REW, pour plusieurs raisons : je vais démarrer la mise au point définitive de mon projet d'enceinte active 3 voies (Hypex) et je souhaite utiliser les mesures effectuées l'année dernière sur maquette à l'échelle 1 en extérieur avec REW. D'autre part, même si LinFIR propose un outil intégré pour effectuer des mesures, j'aimerais pour l'instant conserver mes habitudes...
Je me suis livré à diverses investigations, dont je rends compte dans le PDF joint.
Mes conclusions sont malheureusement les suivantes :
1. Exports Wav non normalisés : inexploitables.
2. Exports Wav normalisés : exploitables à la double condition d'être capable de créer des offsets de niveau dans le DSP (pas très compliqué), et de créer des offsets de delay sur la position des impulsions, mais est-ce seulement possible ?
3. Exports frd : apparemment inexploitables.

Mais j'ai peut-être commis des erreurs dans mes investigations ou dans les conclusions que j'en ai tiré.
Je reste preneur de toute suggestion pour avancer !

Pascal

[cgo75]

Un grand merci à Arnaud pour la version 1.4.3. J'avais les pires difficultés à faire des mesures en ASIO sous Windows 10: il y avait toujours une erreur de timing ou de buffer qui n'était pas correct.
Avec la version 1.4.3, non seulement la mesure se fait sans douleur (vérifié sur deux ordinateurs différents sous Windows 10), mais on peut afficher des courbes de réponse en fréquence jusqu'à la fréquence de nyquist. On n'est plus limité à 24 KHz.
Ceci permet par exemple de faire des mesures de réponse en fréquence et de distorsion sur un ampli de 10Hz à 80 KHz, compte tenu de la bande passante de l'interface USB (à 192KHz) et de sa distortion négligeable
Pour exemple, la réponse en fréquence de l'interface USB SSL2 MK2 en loopback à une fréquence d'échantillonnage de 96K est :

Quand au timing (T0 de la réponse impulsionnelle), il correspond à la valeur de la variable 'Manual Offset' dans les settings soit 1mS pour moi (si on met 0mS, LinFIR n'est pas content)

Puis-je suggérer la prise en compte d'un fichier de correction pour l'interface audio de la même manière que pour le microphone?

Prochaine étape pour moi: des mesures acoustiques pour vérifier la bonne prise en compte des déphasages entre HP.
Amicalement
Claude

[Arnwald]

Hello @cgo75,

C’est étrange, je n’ai fait aucune modification de la gestion audio pour la 1.4.3. Tu es sûr que ta chaîne de traitement est la même?

La correction de l’interface via un filtre de Kirkeby est sur ma TODO list. Je cherche encore la meilleure façon de l’intégrer, mais cela se fera probablement via une mesure par un loopback dans les réglages audio. Je dois en revanche tester la stabilité et trouver le bon compromis pour ne pas amplifier le bruit.

Une mesure rejetée avec un délai de synchronisation de 0 ms est normal, une partie de l’impulsion se retrouve tronquée quand la latence est extrêmement faible (comme dans le cas d’une mesure entrée-sortie directe). Cela ne poserait pas de problème avec une mesure d’enceinte si le microphone est positionné suffisamment loin.

Arnaud

[Sensunda]

Bonjour Pascal

D'autre part, même si LinFIR propose un outil intégré pour effectuer des mesures, j'aimerais pour l'instant conserver mes habitudes...

Mouais, moi je serai quand même d'avis, de vérifier la cohérence entre REW et LinFIR pour les mesures aussi

Je me suis livré à diverses investigations, dont je rends compte dans le PDF joint.

Plusieurs points me font réagir.

Que tu exportes la mesure brute (pas sur que la fenêtre soit prise en compte, elle agit normalement que au niveau du soft) ça OK, mais ensuite il faut choisir entre l'export 2 ou 3, mais exporter les 2 ne sert à rien. Et quand tu désires extraire la la mesure en ayant placé le début de l'impulsion à T=0 (retrait du temps de trajet jusqu'au micro), pour s'assurer que le travail a été bien fait, il faut pour cela générer dans REW la phase minimale, qui est un phase calculée à partir de la courbe d'amplitude en fréquence, si les courbes se superposent avec celle de phase ramenée à 0 (donc l'excess de phase à 0), c'est bon, sinon il y a un souci.

Bien sûr une seule des mesures sur les 3 HP doit-être alignée à T=0 (la première), les autres doivent se voir retranchées ce même temps pour garder la cohérence de délai entre les HP .

Outre ces problèmes de posi on d'impulsions, on a également à résoudre la ques on du rétablissement des niveaux rela fs. L'importa on dans LinFIR de fichiers Wav au format normalisé met le désordre dans leurs niveaux rela fs, comme on peut le voir ci-dessous.

Ça ce n'est clairement pas normal .

[Arnwald]

Hello,

Je me permets de répondre...

Quand on ramène l'IR à t=0, on prend le risque d'en tronquer une partie et d'introduire à la fois des artefacts de magnitude et de phase. A fortiori si l'IR ne contient pas que du "signal phase minimum", ce qui en pratique est toujours le cas car elle contient le pre-ringing causé par le départ du sweep à une fréquence différente de DC (0 Hz).

Il est donc préférable de toujours laisser entre 5 à 10 ms entre le premier échantillon (t=0) et le pic de l'IR.

Le décalage observé de 15 µs provient très probablement du rééchantillonnage. Toutes les données sont ajustées à la Fs du DSP cible, ce qui permet d'appliquer exactement les filtres FIR et IIR qui seront exportés pour le DSP. C'est une contrainte du WYSIWYG, mais l'écart observé est le même pour toutes les voies, donc il ne pose pas de problème pour l'alignement temporel.

Pour ce qui est de l'importation de fichiers normalisés, il est parfaitement normal que les niveaux relatifs soient perdus... Si on demande à REW de normaliser, alors trois IR dont le pic se situe respectivement à 0.5, 0.6 et 0.7 (en domaine temporel cela revient à des échantillons dont la valeur en est à -6.02 dB, -4.44 dB et -3.1 dB) se retrouveront toutes trois à 1.0. Ici c'est en domaine temporel, cela ne veut pas dire que les contenu fréquentiel vaut ces valeurs, par contre les niveaux sont respectivement décalés de +6.02 dB, +4.44 dB et +3.1 dB sur tout le spectre. Ici, REW a bien fait son job et LinFIR n'y est pour rien.

J'ai introduit la limite des -25 dB pour les mesures et importations pour forcer une bonne pratique: celle d'ajuster le gain pour maximiser le rapport signal sur bruit et améliorer les résultats. Et je l'ai fait précisément suite à un message reçu sur un forum portant sur la qualité de la création des filtres, mais il s'est avéré que la mesure était noyée dans le bruit.

Cela étant dit, maintenant que j'ai pu travailler sur la documentation pour alerter sur ce type d'erreur, je vais assouplir la limite dans la prochaine version en laissant le choix à l'utilisateur d'importer quand même l'IR.
En revanche, la limite du pic situé à plus de 200 ms restera: elle est clairement le symptôme d'un problème de la synchronisation des mesures (ce qui est crucial pour les crossovers) ou d'une IR brute de déconvolution contenant également les pics de distorsion harmonique.

Arnaud

[cgo75]

Hello @cgo75,

C’est étrange, je n’ai fait aucune modification de la gestion audio pour la 1.4.3. Tu es sûr que ta chaîne de traitement est la même?

Oups! dans mes premiers essais, j'avais croisé les canaux 1 et 2 dans le loopback de la carte son

[JIM]

Quand on ramène l'IR à t=0, on prend le risque d'en tronquer une partie et d'introduire à la fois des artefacts de magnitude et de phase. A fortiori si l'IR ne contient pas que du "signal phase minimum", ce qui en pratique est toujours le cas car elle contient le pre-ringing causé par le départ du sweep à une fréquence différente de DC (0 Hz).

Il est donc préférable de toujours laisser entre 5 à 10 ms entre le premier échantillon (t=0) et le pic de l'IR.

Bonjour,

Je ne connais pas ce logiciel, utilisateur de Rephase depuis le début avec le même besoin d'un système entièrement filtré en FIR.
Personnellement et depuis toujours (hors configuration à faible latence), je cale le pic d'impulsion à mi fenêtre.
Option centering sur Rephase. La latence est donc fixée par le nombre de taps /2 fs.
Dans mon cas, 32768 taps par voie à fs 96000 Hz donne 170ms de latence.
Le décalage de temps entre hp est soit géré en dehors de l'impulsion de filtrage soit en déplaçant l'impulsion avec l'option "centering +- x ms".
Le délai pur réduis le nombre de taps utile pour le filtrage, il ne faut pas en abuser.

[Arnwald]

Quand on ramène l'IR à t=0, on prend le risque d'en tronquer une partie et d'introduire à la fois des artefacts de magnitude et de phase. A fortiori si l'IR ne contient pas que du "signal phase minimum", ce qui en pratique est toujours le cas car elle contient le pre-ringing causé par le départ du sweep à une fréquence différente de DC (0 Hz).

Il est donc préférable de toujours laisser entre 5 à 10 ms entre le premier échantillon (t=0) et le pic de l'IR.

Bonjour,

Je ne connais pas ce logiciel, utilisateur de Rephase depuis le début avec le même besoin d'un système entièrement filtré en FIR.
Personnellement et depuis toujours (hors configuration à faible latence), je cale le pic d'impulsion à mi fenêtre.
Option centering sur Rephase. La latence est donc fixée par le nombre de taps /2 fs.
Dans mon cas, 32768 taps par voie à fs 96000 Hz donne 170ms de latence.
Le décalage de temps entre hp est soit géré en dehors de l'impulsion de filtrage soit en déplaçant l'impulsion avec l'option "centering +- x ms".
Le délai pur réduis le nombre de taps utile pour le filtrage, il ne faut pas en abuser.

Ici il était question de l'IR du haut parleur, mais c'est un peu la même idée que pour un filtre: si on tronque une partie en positionnant le pic trop proche de t=0, on perd de l'information...

[Dagda]

Surtout que dans REW, tu peux définir la position de t=0 au niveau du pied du pic, ou au niveau du pic ... Et au pied comme avec le Estimate IR Delay, on est à un pourcentage du début du pied (autour de 8%) si je me souviens bien de mes lectures.
Donc, obligatoirement, on coupe de l'information en amont.

[JIM]

J'imagine que dans ce cas, il ne faut pas caler le t=0 au pic d'impulsion mais à une référence de temps commune à l'ensemble des mesures et avec suffisamment de marge en effet pour prendre la totalité de la mesure.
A ce stade, il n'y a pas vraiment de limites de taps. REW prend 125ms de marge à gauche avant le pic d'impulsion par défaut.

[Dagda]

Il est donc préférable de toujours laisser entre 5 à 10 ms entre le premier échantillon (t=0) et le pic de l'IR.