Correction/filtrage semi-automatisé (DStudio v5)

[thierryvalk]

Au final suis pas vraiment sur ce que ce soit un gros problème.
Il y a au niveau de l'Impulse que l'on peut avec 2 Fs : 48K pour tout ce qui est mesure, mais en FIR 48 ou 96.
Si on laisse l'exception rare du FIR 96K, on a des Impulses en 48K dont on calcule la FFT.
On est maintenant en fréquentiel et sauf erreur plus (pas) dépendant de la Fs.
Pour la suite, tout ce qui est calcul est bien fait avec la Fs de l'Appli et les délais en secondes (calculés avec la Fs de l'Appli).

[thierryvalk]

Je commence a penser à système de mesure de calage des HP.
Le but est d'avoir quelque chose de simple, efficace et sans mauvaises surprises.

L'idée est de générer 2 burst, à fréquence de coupure des 2 HP, pour plus d'info
viewtopic.php?f=2&t=95
Vu que l'on a le DSPiy sous contrôle, il est imaginable d'avoir un fichier avec ces 2 burts et de commuter le signal de sorties pendant que le fichier joue.

Petit dessin :

En rouge, le fichier a lire, tp1 serait 0.5s et tp2 1.5s ( je donne des chiffres sans trop y avoir réfléchi).
Ce timing est en nombre de sample donc fiable.
On active par soft uniquement la sortie Low du DSPiy, on lance le fichier et on enregistre.
tc représente une inconnue qui est le temps mis par Windows et carte son pour commencer l'enregistrement.

A l'instant tp1 1er burst, on attend qu'il soit capté par le micro puis l'on coupe la sortie Low pour activer uniquement la High.
A l'instant tp2 le second burts qui sera lui aussi enregistré dans le même fichier.

Si l'on fait tr1-tp1 on aura la distance approximative entre le micro et le HP Low avec une erreur de tc.
Idem pour le HP High en faisant tr2-tp2.
Vu que tc est identique on saura quel HP est en avance par rapport à l'autre, et avec tr2-tr1 de combien de temps.

L'avantage de le mesure est de ne pas demander un canal de référence sur la carte son, fonctionne à la fréquence de croisement donc là ou c'est important.
Inconvénient, le burst enregistré peut dans certains cas être pas mal déformé et donc pas si simple de bien trouver son point milieu.

[alka]

C'est sur que c'est un gros avantage de controler les voies avec le DSPiy

Si tu es sûr d'ouvrir le fichier en lecture en même temps que tu commences a émettre (cad que t0 est le même des deux cotés) ta technique est ok (bien que la représentation de tc sur le dessin prête a confusion pour moi).

Sur ton dessin on a l'impression que c'est le même délai entre les bursts bleus et rouges et qu'il n'y a qu'un décalage global entre les deux lignes. Il y a bien deux décalages : celui dû a la propagation qui décale l'ensemble et celui dû au calage des HPs qui décale les deux burst bleus entre eux.


Une alternative qui ne dépend pas de t0, lisible dans le fichier reçu sans connaitre l'origine des temps :
On connait par construction deltaTp = tp2 - tp1 (durée entre les burst émis)
On mesure deltaTr = tr2 - tr1 (durée entre les burst reçus)

le temps de calage entre les HPs est tc = deltaTr - deltaTp
Reste a pas se gourer de sens

Pour la déformation probable des burst, ça me fait réfléchir. Comme on choisit Fc a un endroit ou les deux HPs sont bons, ils ne devraient pas etre trop déformé. On peut ouvrir le fichier enregistré dans audacity et constater de visu.

[thierryvalk]

Si tu es sûr d'ouvrir le fichier en lecture en même temps que tu commences a émettre

Non, justement c'est pour cela que j'ai mis tc qui peut être négatif.

On mesure deltaTr = tr2 - tr1 (durée entre les burst reçus)

C'est bien ce que j'ai écrit.

Reste a pas se gourer de sens

C'est pour cela que je mesure aussi les décalage avec les bursts émis.

On peut ouvrir le fichier enregistré dans audacity et constater de visu.

J'imagine plus les afficher directement dans DStudio.
On peut imaginer faire tourner en boucle le mécanisme et afficher les 2 burts reçus superposés avec même la sommation des 2.

[alka]

on est d'accord. C'est juste que , bien que calculé correctement, dessiner tc a cet endroit là est confusionnant pour moi. Ca donne l'impression que c'est un temps de recul entre le départ de la rouge et le départ de la bleue.

[alka]

je profite de la pause café pour faire un dessin a ma sauce, (bursts représentés par un simple pic)

Ca dit la même chose différemment.



Les deux pics rouges sont à l'émission, l'un sur HP1 et l'autre sur HP2
Les deux pics bleus sont les enregistrements respectifs de HP1 et HP2.
Connaissant t0, on peut calculer prop , le temps de propagation du signal qui permet de déterminer la distance micro-HP1.
dp est le délai entre les deux pics émis
tc est le temps supplémentaire dû au décalage entre les deux HPs. Ici, HP2 est plus loin que HP1 et tc > 0. Si HP2 est plus proche, tc < 0.


reste la trigonométrie! Tout ça est parfait pour un HP coaxial, mais si on est dans le cas d'une enceinte deux voies et qu'on met pas le micro très loin , faudra ajuster le délai en conséquence de l'angle alpha.


la méthode ci-dessus permet de calculer la différence de temps de parcours tc entre le trait bleu et le rouge
le décalage d = tc * 343 * cos(alpha). d en mètres

[thierryvalk]

Ton tc n'est pas le même que le mien et t0 n'est pas spécialement égal à l'autre t0.
En effet, on fait Play puis REC ou inversement, dans certains cas le micro sera sur carte Son et la source en USB DSPiy par exemple.
Bien que ce n'est du tout conseillé vu qu'avec des cartes son différentes on peut avoir des vitesses différentes, mais l'erreur sera négligeable lorsque les centres alignés.
Dans certain cas le temps de latence sera très grand, en FIR par exemple.

Pour la trigo, oui, l'idéal étant d'avoir une distance micro/enceinte bien supérieure à l'entre-axe des HP et idéalement au point d'écoute.

[alka]

En fait j'avais interprété la discussion comme la mesure du décalage géométrique des centres d'émission qui se fait en principe sans aucun filtrage en place. On peut bien sûr se servir de cet outil pour trouver le délai de calage de HPs filtrés. C'est un outil, et on en fait ce qu'on veut.

micro loin c'est idéal, ca donne alpha voisin de 0 et cos(alpha) voisin de 1. Mais c'est pas toujours possible.
En faisant une simulation meme sur un cas extreme, l'erreur introduite par l'omission de cos(alpha) est relativement faible. En mettant le micro loin ou vaguement face a HP2 ça suffira.

Pour prop tu as raison, c'est le temps intégral de propagation et inclus le délai de traitement des cartes son et dspiy ce qui en FIR n'est pas négligeable mais connu. On peut quand même en déduire la distance micro-HP1. Information pas forcément utile, on est bien d'accord.

[thierryvalk]

Encore des courbes, mais cette fois c'est différent; il s'agit du filtrage soustractif.

Par contre, les phases font n'importe quoi et ce que je ne comprend pas c'est que la courbe Simu totale reste toujours à zéro, même si je change les délais des soustracteurs.
Pourtant la courbe est bien l'addition de ces 3 là et si je change le délai d'une voie là, la totale varie apparemment correctement.
Une idée ?

[alka]

t'as pu vérifier que la phase de chaque voie est ok ?

[thierryvalk]

C'est pas OK.
Si je prend que la voie Low qui n'est qu'un simple passe-bas, la phase est différente en courbe Filtre et Simu alors que Simu n'est que Filtre * Mesure dont cette dernière n'existant pas est normalement "neutre".
Il doit y avoir un débordement quelque part, verrais demain s'il y a de la pluie.

[thierryvalk]

Le point de la situation.

On peut faire des mesures directement depuis DStudio, les afficher et faire y appliquer des corrections par voie.
C'est bien et utile.
Par contre, si l'on fait une mesure avec déjà des filtres en place, la simu sera faussée, j'en ai déjà parlé.

Par contre, la sommation des voies bien qu'existante n'est pas vraiment pertinente vu qu'il manque l'aspect "temporel".
Pour avoir une simu juste, il faudrait que DStudio connaisse les décalages des HP.
C'est faisable, mais à un moment donné c'est presque plus de boulot que d'avoir une simu juste que d'avoir son filtrage en réel juste. Et ça c'est pas terrible surtout mis en rapport avec le boulot conséquent au niveau du soft déjà fait et celui qu'il faudrait encore faire.
Et le truc, c'est que dès que l'on met du délai, les phases deviennent illisibles.

Je pense que j'aurais du me limiter au travail HP par HP pour le crossover, outil de d'alignement via générateur de burst puis via une mesure de l'enceinte voir les corrections globales et voir plus loin avec le soft DRC.

Mais vu que tout ceci ne semble pas passionner la foule et que l'on va vers les beaux jours, je verrais tout cela tranquillement.

[alka]

les foules sont en attente difficile de contribuer a ce stade. Parfois l'offre créé la demande.
J'avoue que je ne comprend pas trop le souci de la sommation. Un délai est un filtre comme les autres. Si on entre un délai manuellement sur une ou plusieurs voies, la somme sera juste.

Peut etre prévoir une première version opérationnelle , avec des limitations mais avec les outils déjà disponibles et qui représentent des fonctions tout a fait utiles ?
Ensuite sélectionner l'ordre des priorités.

C'est pas simple d'obtenir du feedback a la fois pertinent, en nombre et simultané car tout le monde n'a pas une enceinte a mettre au point pile a la date de sortie de DStudio. Peut etre mettre l'accent sur ce qui est faisable en room eq et qu'on peut faire n'importe quand. Mesure sweep ou pinknoise au point d'écoute, moyennes, simulation correction, vérification.

[*dfer]

les foules sont en attente difficile de contribuer a ce stade. Parfois l'offre créé la demande.

+1
Je ne suis pas en mesure d'apporter ma pierre à l'édifice (avec regret) mais j'apprécie ton investissement.

[manudrz]

Tout pareil, par contre j'ai des pseudos enceintes à mettre au point là mais pas énormément de temps libre à y consacrer... Il faut que je commence par relire ce sujet déjà !

[androuski]

Moi aussi,
j'ai manifesté mon vif intérêt
Mais prends ton temps, je crois que personne n'est aux pièces ici
Par contre même vu de loin ça semble décourageant...

[thierryvalk]

Décourageant, oui, mais très intéressant, j'ai appris plein de trucs.
Mais a un moment on remarque que c'est sans fin et de se rappeler que le but de base était de faire quelque chose d'utile et non refaire un truc encore lourd et coincé de ce qui se fait déjà.

[thierryvalk]

Comment faire du RTA périodique.
Le but est de faire la fonction Pink PN de REW.

Ce dont on dispose :
Fichier que l'on crée avec Sox et qui sera lu par le player.
Au lancement de la lecture, on lance un enregistrement mais sans enregistrer dans un fichier.
Pour cela on a un événement qui est créé lorsque l'on a T samples lus dans un buffer.
T est en millisecondes entières.

Ce que j'ai fait :
Défini T à 683ms ce qui fait 32784 samples, la FFT étant de 32768 samples.
Récupération du buffer, offset du niveau, FFT 32K et affichage tout en remettant le pointeur du player à zéro.
Évidemment ne fonctionne pas.

Voici ce que cela donne en passant dans un DSPiy avec un LR48 à 1K.
En rouge, Mesure normale, en violet le RTA :

Déjà je pense avoir une erreur de calcul quelque part vu que pour la Mesure j'applique -2dB d'offset et -50 en RTA.
Mais la courbe violette étant périodique ne devrait pas bouger ce qui n'est pas le cas.