LinFIR - Mesures et égalisation FIR/IIR

[pvrx]

@razzortec
J'ai rencontré ce genre de pb avec ma carte son Motu 2.
J'ai accès au gain d'entrée et de sortie de la carte, que je ne peux régler qu'avec des boutons rotatifs sans repérage de niveau. J'ai fini par trouver des positions de boutons permettant la mesure.
Mais il faut recalibrer le micro à chaque fois que tu modifies la position de ces boutons.

Pascal

[Arnwald]

Bonjour
Un plus haut , je vous avais parlé de la difficulté de faire des mesures avec un PC fixe sous WIN 10, je l'ai passé en WIN11 et cela a fonctionné quelques jours, puis Linfir se plantait lors de la recherche de la carte son, alors que j'avais bien du son en utilisant REW ou depuis le gestionnaire de windows.

J'ai pris le portable de ma femme (Win 11), et j'ai fait des mesures toute la semaine dernière, tout fonctionnait correctement.
Ce matin je voulais continuer mes mesures , et plus aucun son, alors que cela fontionne depuis le gestionnaire de sons de windows

LinFir m'indique ceci, amors que j'ai 2 entrées et 2 sorties
carte son 2 11 26 portable - Copie.png


La mesure est impossible meme en abaissant le niveau
Mesure anulée - Copie.png

Juste pour info, sur mon PC fixe, lorsque je branche la carte son, j'ai 2entrées et 4 sorties

carte son PC fixe.png

Je suis en version 1.52 sur les ordi

Salut razzortec,

Pour l’écrêtage : en mode « Électrique (boucle) », LinFIR envoie sur la sortie de référence (la 2 chez toi) un court signal de synchronisation à niveau fixe, qui ne dépend pas du niveau de mesure. C’est l’entrée de référence (l’entrée 2 de ta Yamaha) qui sature, pas l’entrée micro. C’est pour ça que baisser le niveau de mesure n’y change rien. Il suffit de baisser le gain de l’entrée 2 sur ton interface, jusqu’à ce que le signal de référence ne sature plus (le témoin de clip de l’interface doit rester éteint). La prochaine version dira clairement quelle entrée écrête et quoi faire.

Pour « 1 entrées, 1 sorties » : ce chiffre compte les périphériques audio que LinFIR trouve, pas les voies. Avec ASIO, ta Yamaha est le seul périphérique, d’où 1 et 1. Ses 2 voies sont bien vues, c’est le « 2 voie(s) max. » à côté du périphérique. L’affichage sera plus clair dans la prochaine version (« Périphériques : 1 en entrée, 1 en sortie »).

Peux-tu suivre la procédure pour envoyer un rapport de bug? Il faut activer le mode verbose dans les settings, puis Aide > Signaler un bug. Le rapport joint le journal de LinFIR, qui me dira où ça coince. Précise aussi la version de Windows et celle du pilote Yamaha Steinberg USB.

Les joies de l'audio sous Windows...

Arnaud

[Arnwald]

J'ai fait l'essai avec HFD v5.0 et avec HFD v5.3.1, et avec un xml "ancien" et un récent.
En fait, je me retrouve avec des délais à 0 avec la v5.0 et à0,019ms avec la v5.3.1, autant dire 0.
Où ces délais sont-ils passés ?
Sont-ils intégrés dans les FIR ?
Et si c'est le cas, comment puis-je effectuer une correction de délai dans le dsp ?

Pascal

Bonjour Pascal,

J’ai creusé la question. Pour résumer : de mon côté, l’export fonctionne. J’ai créé un projet de zéro avec des retards sur les voies, je l’ai exporté depuis LinFIR, puis ouvert dans HFD 5.0 et dans HFD 5.2.4, la dernière version publiée par Hypex. Dans les deux cas, les retards arrivent tels quels dans les paramètres de chaque voie.

J’ai aussi vérifié le code. LinFIR écrit le retard de chaque haut-parleur, arrondi à l’échantillon près (93,75 kHz), dans le bloc de retard de la voie correspondante. C’est exactement le même calcul en mode Hypex et en mode Loudspeaker Design. J’ai reproduit ta configuration (FA503, FIR en sortie, 3,573 / 1,056 / 0 ms) : le fichier généré contient bien 3573 µs pour la voie 1 et 1056 µs pour la voie 2.

Les retards ne sont pas intégrés dans les FIR. Les filtres FIR sont exportés sans retard, sans gain et sans inversion de polarité : ces trois réglages vont dans les paramètres de chaque voie du DSP, là où HFD les affiche. C’est un choix délibéré : un retard intégré au FIR mangerait des coefficients et tronquerait le filtre, alors que le DSP fait un retard sans aucun coût.

Le problème se situe donc entre le fichier exporté et ce que HFD en affiche chez toi. Tu parles de HFD 5.3.1, alors que la dernière version publiée que je connaisse est la 5.2.4 : peux-tu vérifier la version exacte ? Et si tu peux m’envoyer en MP le xml exporté par LinFIR, je regarderai précisément ce qu’il contient.

Cela dit, tu n’as plus besoin de passer par HFD. Depuis la version 1.5, LinFIR pilote directement les FA503 par USB (menu Affichage > Hypex DSP Manager). Il envoie les FIR, les filtres IIR, les gains, les retards et l’inversion de polarité de chaque voie, dans le préréglage de ton choix. Pour ajuster un retard ou un gain après mesure, il suffit de le modifier dans ton projet LinFIR et de renvoyer le projet au module : c’est l’affaire de quelques secondes, et tu gardes un seul endroit où tout est réglé.

Au passage, merci pour les captures : elles m’ont fait repérer un mélange de virgules et de points dans les nombres affichés en français, et un défaut de mise en page de la fenêtre d’export HFD. Les deux sont corrigés pour la prochaine version.

Arnaud

[Sensunda]

Les joies de l'audio sous Windows...

Comment fait REW pour ne pas être trop embêté à ce niveau ? Je me doute que tu t'arraches déjà bien les cheveux sur cet problématique mais au cas j'aide (enfin j'espère) avec le peu d'imagination que j'ai dans ton domaine

[Arnwald]

Les joies de l'audio sous Windows...

Comment fait REW pour ne pas être trop embêté à ce niveau ? Je me doute que tu t'arraches déjà bien les cheveux sur cet problématique mais au cas j'aide (enfin j'espère) avec le peu d'imagination que j'ai dans ton domaine

Honnêtement, REW est simplement plus souple que LinFIR sur ce point, et c'est un choix assumé de ma part. LinFIR met l'accent sur la synchronisation des signaux : pour concevoir un crossover, il faut que les temps de vol relatifs entre haut-parleurs soient justes, et que les harmoniques tombent exactement là où la théorie du sweep les attend. Donc avant d'accepter une capture, LinFIR vérifie que l'entrée et la sortie ont démarré quasiment en même temps, que le sweep est bien présent dans l'enregistrement, que H2 ne déborde pas sur la réponse impulsionnelle, etc. Si quelque chose cloche, il refuse la mesure plutôt que de te donner un résultat faux qui a l'air juste. REW est plus tolérant, il prend l'enregistrement tel qu'il arrive et laisse l'utilisateur juger.

Le problème, c'est que Windows est un enfer pour l'audio temps réel. Entre MME, DirectSound, WASAPI et ASIO, chaque API a son propre comportement, et aucune n'est vraiment fiable. Avec WASAPI, rien ne garantit que l'entrée et la sortie démarrent ensemble, ni même qu'elles tournent à la même fréquence d'échantillonnage. ASIO n'est pas la solution miracle qu'on imagine non plus : selon les drivers, il est instable et remonte mal ses erreurs. Et par-dessus tout ça, il y a la latence DPC et la priorité des threads : il suffit qu'un driver, vidéo par exemple, garde la main un peu trop longtemps pour que le buffer audio se vide. J'ai dû monter la priorité des threads ASIO dans LinFIR pour limiter les craquements. Pour te donner une idée, avec la même carte son, je ne peux pas descendre aussi bas en taille de buffer sur un gros ZBook i7 que sur un vieux MacBook M1, et le jitter se voit directement sur la courbe de phase.

Et je ne suis pas le seul à m'arracher les cheveux. LinFIR s'appuie sur cpal, une bibliothèque audio en Rust, et ses développeurs se battent depuis des années avec les plantages ASIO et le modèle de threads COM de Windows. Je profite de leur travail, mais ça reste fragile. Le développeur de VVVV.Audio a mis son support WASAPI en pause faute de pouvoir synchroniser l'entrée et la sortie avec une latence acceptable. Celui de Psychtoolbox, un outil d'expériences de psychophysique où le timing est critique, a passé une journée entière sur un problème similaire pour conclure à des bizarreries de WASAPI côté entrée. Stereo Tool a même dû forcer lui-même la synchronisation des démarrages entrée/sortie.

Pour être tout à fait franc, LinFIR est le dernier logiciel que je développe qui supportera cet OS, ça me fait trop perdre de temps.

Là je travaille sur un logiciel multi-physique (LEM. BEM et FEM) dédié à l’acoustique (guides d’ondes, rayonnement de l’enceinte complète, acoustique des pièces), et il sera Mac only. Il me serait de tout façon impossible d’offrir les mêmes performances sur un PC, l’architecture Silicon et sa mémoire partagée est impossible à égaler sur ce type de calculs où les données passent alternativement du CPU au GPU. ;-)