Egalisation sous Linux avec le framework AVDSP de maxidcx

» 03 Fév 2021 17:53

bon, je voulais en avoir le coeur net, voila qui est fait:
un programme dsp qui prend du stereo en input et le convertit en 2 canaux headphones avec 4 peq, et 6 canaux pour faire un 2x3voies, en base LR4 avec 4 peq et un ajustement de delais sur chaque canaux. le tout avec une source DSD256 lue par mpd, convertie en pcm192k 32 bits qui traverse le dsp a ce bitrate : 56% cpu load sur rpi4. nickel.

en clair, dégager tous les DSP du monde, utiliser un streamer rpi et connectez le a un dac 8 sortie (motu 8a, dac8pro...) et vous avec la meilleur soluce waf compatible. et en joker la possibilité de faire du filtrage soustractif ...
:ohmg:

reste plu qu'a faire un plug in html/js qui intègre tout ca dans l'interface volumio avec parametrage des fréquences et visu de la courbe... vivement le prochain confinement

» 03 Fév 2021 18:58

Perso j'avais envisagé un kit RPI + 2FDA usb genre SMSLAD18, genre le streamer filtre actif deux voies à moins de 400 euros

tout compris.
Le truc cradaux c'était la gestion du volume ....

» 03 Fév 2021 19:39

Non, il n'y a pas de pb de gestion de volume. Un volume numérique, dans le player, ne pose aucun problème quand on a correctement réglé les gains analogiques.
Par contre la synchro de deux DAC, je demande à voir (je dis pas que ca ne marche pas) ....
maxidcx utilise une solution de luxe avec l'okto, mais une MOTU 4 voies peut aussi faire l'affaire.

Sinon, pour le plugin AVDSP, je l'utilise depuis pas mal de temps maintenant :wink:

, dernièrement avec une config LMS/squeezelite. Mais je ne fais pas de filtrage juste de la correction globale.

» 05 Fév 2021 11:40

Bonjour,
j'ai fait pas mal d'essais avec Volumio et il s'avère que assez souvent Volumio écrase les fichiers de configuration en remplaçant le nom du device de sortie audio. Dans mon cas il est systématiquement remplacé par "hw:5,0" pour pointer directement vers le dac, sans passer par le plugin dsp.

Du coup je me lance dans la creation d'un "plugin volumio" pour assurer que le flux alsa sera toujours bien configuré.
le github correspondant avec le folder specific volavdspio est ici pour ceux qui voudront suivre ou forker:
https://github.com/fabriceo/volumio-plu ... volavdspio
il apparait ainsi:

mon intention c'est de faire une premiere version élémentaire qui permettait d'activer le plugin ou pas, et de sélectionner le fichier de dspcode à utiliser, cela donnerait une fonction similaire a une selection de preset.

dans une deuxième version on pourrait sélectionner le module REQgenericEQ développé par tcli et documenté dans le premier post de ce topic, et permettre de lister des fichiers de filtres REW au format texte

après on peut imaginer de pousser l'application un cran, pour faire de la creation de fichier dspcode dynamiquement (à la manière de REWgenericEQ) à partir d'une liste de paramètres structurés tels que

on va avancer progressivement et je reviendrais sur ce topic quand il y aura une version substantiellement fonctionnelle avec Volumio

» 05 Fév 2021 15:49

maxidcx a écrit:Du coup je me lance dans la creation d'un "plugin volumio"

Ca va commencer à être très intéressant.

maxidcx a écrit:Verdict après 1 heure de streaming dlna d'Alchemy sacd converti en flac88k sur un NAS en wifi, et bien tout est nickel : un raspy est totalement fiable vis a vis d'un dac à base d'XMOS.

L'inverse aurait été plus qu'étonnant.
On peut penser que ceux qui écrivent les drivers USB Linux testent un minimum ce qu'ils font et vérifient qu'ils ne perdent pas des bits en route. :mdr:

» 05 Fév 2021 20:28

Mes respects !
Très intéressant en tout cas

après vu le contexte, vais pas me plaindre de ne pas avoir le temps mais zut je testerais bien

» 23 Mar 2021 8:34

tcli a écrit:On peut penser que ceux qui écrivent les drivers USB Linux testent un minimum ce qu'ils font et vérifient qu'ils ne perdent pas des bits en route.

Tant qu'on cuit bien son cable usb avant de tester, pas de raison de perdre de bits en plus des euros lol !

Un grand bravo pour avdsp ! Ça comble un vide, j'ai jamais trouvé mon bonheur pour faire un filtre actif sous Linux avec convolution sans resampling. Obligé de me rabattre sur macosx, une motu 624 et jriver / mcfx.

Bravo

Envoyé de mon VOG-L29 en utilisant Tapatalk

» 26 Avr 2021 10:46

Salut,
je reviens rapidement sur ce sujet après quelques essais pour proposer une solution d'integration qui fonctionne:

maxidcx a écrit:Bonjour,
j'ai fait pas mal d'essais avec Volumio et il s'avère que assez souvent Volumio écrase les fichiers de configuration en remplaçant le nom du device de sortie audio. Dans mon cas il est systématiquement remplacé par "hw:5,0" pour pointer directement vers le dac, sans passer par le plugin dsp.

alors effectivement, Volumio écrase les fichier de conf de mpd et de shairport-sync dès qu'on modifie les réglages.
On peut se retrouver avec une lecture audio qui passerait directement vers la carte audio, sans passer par le plugin avdsp.
Dans le cas d'un crossover actif multi-voies çà pourrait tourner à la catastrophe.
Du coup je préfère une solution radicale qui est d'intercepter les flux audio qui sont routés vers hw:x,y.

l'idée est de surcharger le code alsa pcm.hw { ... } qui se trouve dans /usr/share/alsa/alsa.conf grace à un statement pcm.!hw { ... } .... par l'action magique du point d'exclamation :grad:

après quelque recherches et tests, il suffit de créer un nouveau fichier hwintercept.conf dans le repertoire /usr/share/alsa/alsa.conf.d
Son contenu sera systématiquement chargé au lancement de alsa, et avant les fichiers /etc/asound.conf et ~/.asoundrc qui resteront donc prioritaires.
Il doit etre crée avec les privilèges root avec sudo nano /usr/share/alsa/alsa.conf.d/hwintercept.conf

le contenu entre crochet de pcm.!hw doit tout simplement être un copier/coller de ce qu'il y a normalement dans pcm.hw, mais on change les lignes entre type hw et subdevice $SUBDEV par

Code: Tout sélectionner: type empty slave.pcm { @func concat strings [ "hw" $CARD $DEV ] }

De cette façon, toutes les flux vers hw:x,y ou x est votre numero de carte hardware (et y à 0 pour les cartes usb) sont redirigées vers un nouveau pcm dont le nom est hwxy.
Il suffit de declarer ce que doit faire pcm.hw50 pour rediriger le flux:

Code: Tout sélectionner: pcm.hw50 { type avdsp dspprog "/mydir/myavdsp.bin" slave.pcm dac8pro hint { description "card 5,0 now routed to avdsp plugin" } } pcm.dac8pro { type hw card 5 device 0 hint { description "card 5 is my DAC8PRO" } }

voici un exemple du fichier

hwintercept.conf.txt: (978 Octets) Téléchargé 125 fois

remarque: cette approche fonctionne aussi pour le plugin cudaFIR

pour ce qui est de développer un plugin volumio, jai eu l'occasion de bricoler un peu ce sujet, on est assez vite limité sur les possibilités de parametrages. je laisse de coté cela quelques temps.

» 08 Oct 2021 15:18

Salut
pour ceux qui tenteraient d'installer tout çà sur les dernières version de volumio, il ya un problème dès l'installation de gcc avec les "build-essential". (voir forum volumio). la dernière version compatible sans problème est la 2.873 (avant Tidal connect en fait)
il convient donc de flasher une SD card avec cette image que l'on trouve ici :
https://updates.volumio.org/pi/volumio/ ... pi.img.zip
après avoir installé gcc et avdsp, vous pourrez ensuite faire une mise à jour "OTA" de volumio en allant dans la section réglages/systeme de l'interface web volumio.local

» 05 Déc 2021 18:20

salut
avec volumio 3.163 (distribution buster) l'installation des build-essential ne pose pas de problème. voici les sequences à lancer avant d'installer et de compiler avdsp:
sudo apt-get update
sudo apt-get install build-essential
sudo apt-get install libsndfile-dev
sudo apt-get install libasound2-dev
sudo apt-get install libusb-1.0
sudo apt-get install cmake

» 25 Oct 2022 8:48

Bonjour
je constate que sur la version 3 de Volumio (sur raspberrypi) il y a des changements dans la gestion du pipeline Alsa, du coup le principe d'interception du device "hw" décrit ci dessus ne fonctionne plus...

en effet, Volumio redéfinit maintenant le fichier /etc/asound.conf avec ces informations:

Code: Tout sélectionner: pcm.!default { type empty slave.pcm "volumio" } pcm.volumio { type empty slave.pcm "volumioOutput" } # There is always a plug before the hardware to be safe pcm.volumioOut { type plug slave.pcm "volumioHw" } pcm.volumioHw { type hw card "DAC8PRODSP4o2i8" }

il attaque directement la "card" (ici DAC8PRODSP4o2i8 ) sans passer par "hw:".
Aussi ce fichier est systématiquement réécrit par l'application Volumio lors d'une relance du service ou d'un reboot.
C'est ce fichier qui est la cause (ligne 2157 environ):

Code: Tout sélectionner: /volumio/app/plugins/audio_interface/alsa_controller/index.js

J'ai essayé pas mal de trucs pour intercepter ce flux, mais in fine ca ne marche pas. Si quelqu'un peux jeter un oeil...

par exemple on peut placer un fichier de configuration dans /etc/alsa/conf.d/, qui est prioritaire au chargement des confs, pour définir le plugin volumioDsp avec un plugin avdsp ou camilladsp:
cat /etc/alsa/conf.d/80-volumiodsp.conf

Code: Tout sélectionner: pcm.volumioDsp { type empty slave.pcm "volumioOut" # slave.pcm "camilladsp" # slave.pcm "avdspplug" }

et ensuite changer /etc/alsa.conf en patchant le fichier index.js ci dessus avec cette commande sed par exemple:

Code: Tout sélectionner: sudo sed -i 's/pcm.volumioOutput/pcm.volumioOutput { type empty slave.pcm "volumioDsp" } pcm.volumioOut/g' /volumio/app/plugins/audio_interface/alsa_controller/index.js

qui va créer un /etc/alsa.conf specific au démarrage:

Code: Tout sélectionner: pcm.!default { type empty slave.pcm "volumio" } pcm.volumio { type empty slave.pcm "volumioOutput" } # There is always a plug before the hardware to be safe pcm.volumioOutput { type empty slave.pcm "volumioDsp" } pcm.volumioOut { type plug slave.pcm "volumioHw" } pcm.volumioHw { type hw card "DAC8PRODSP4o2i8" }

ca marche avec un aplay -v -D volumio xyz.wav, mais pas avec Volumio, donc ni avec mpd ni shairport, qui pourtant utilisent bien le device volumio dans leur sortie alsa d'après leurs fichiers de config... Je sèche.

sinon à part çà j'ai testé rapidos camilladsp, avec son gui. ca fait le job. l'approche de parametrage est différente, en bricolant un peu avec les mixeurs on arrive a faire du soustractif. ca fonctionne en Float64bits alors que par défaut avdsp est en entiers 32bits (mantisse 28bits), il semble que l'execution avec camilladsp soit 2 fois plus rapide. a confirmer quand même. l'avantage c'est qu'il intègre le FIR aussi.