Allo USBridge, une alternative pour bien nourrir un DAC USB ?

[funkyalf]

comme squeezelite fait appel à ALSA ça doit être lui qui doit choisir le format en 32 bits...
be correspond au codage big endian et le à little endian.
en big endian le bit de poids fort est en premier et en little endian c'est le bit de poids faible.
pour pouvoir s'adapter à toutes les interfaces externes je pense qu'on peut changer la représentation.

pour les paramètres alsa utilisé pour alsa

Citation : -a <params>
             Specify parameters used when opening an audio output device.  For ALSA, the  format
             <b>:<p>:<f>:<m>  is  used where <b> is the buffer time in milliseconds (values less
             than 500) or size in bytes (default 40ms); <p> is the  period  count  (values  less
             than  50)  or size in bytes (default 4 periods); <f> is the sample format (possible
             values: 16, 24, 24_3 or 32); <m> is whether to use mmap (possible values: 0 or  1).

les valeurs que tu as dans ton ficher sont en bytes, tu peux jouer sur les paramètres pour voir si ça change quelque chose.
mais je dirais si ça marche touche à rien.

quand à optimiser le son je suppose que tu parles de l'écoute ?
je ne vois rien à installer de mon côté

[Bigga]

(06-10-2019, 12:49 PM)funkyalf a écrit : comme squeezelite fait appel à ALSA ça doit être lui qui doit choisir le format en 32 bits...
be correspond au codage big endian et le à little endian.
en big endian le bit de poids fort est en premier et en little endian c'est le bit de poids faible.
pour pouvoir s'adapter à toutes les interfaces externes je pense qu'on peut changer la représentation.

pour les paramètres alsa utilisé pour alsa

Citation : -a <params>
             Specify parameters used when opening an audio output device.  For ALSA, the  format
             <b>:<p>:<f>:<m>  is  used where <b> is the buffer time in milliseconds (values less
             than 500) or size in bytes (default 40ms); <p> is the  period  count  (values  less
             than  50)  or size in bytes (default 4 periods); <f> is the sample format (possible
             values: 16, 24, 24_3 or 32); <m> is whether to use mmap (possible values: 0 or  1).

les valeurs que tu as dans ton ficher sont en bytes, tu peux jouer sur les paramètres pour voir si ça change quelque chose.
mais je dirais si ça marche touche à rien.

quand à optimiser le son je suppose que tu parles de l'écoute ?
je ne vois rien à installer de mon côté

Oui, je parlais d'écoute.
Tu as répondu précisément à mes interrogations.
Je compte bien suivre ton conseil avisé, ne rien faire puisque ça marche, mais du coup tes infos me posent questions sur mes paramètres ALSA:

-D -a 4096:8096:32:0 -C 5 -n

D'après ce que je comprends de tes explications, chez moi: "b" (buffer time) est à 4096 et "p" (period count) est à 8096, or d'après ton message ils devraient être respectivement en dessous de 500 et de 40 ms. Comment expliquer cela? Est ce que l'unité est différente chez moi? Comment le savoir?

---

J'ai installé, sur les conseils de Zaurux, récemment, un script d'optimisation audio sous Linux (Qui est censé optimiser l'utilisation du CPU pou l'audio):

Automated Install
Code :
curl -sSL https://github.com/dynobot/Linux-Audio-A...install.sh | bash


Automated Removal
Code :
curl -sSL https://github.com/dynobot/Linux-Audio-A.../remove.sh | bash

Peut être est-ce cela qui a changé certains paramètres?
En toute honnêteté, je n'ai pas remarqué de mieux ni de moins bien au niveau sonore avec ce script chez moi. Je pourrais le désinstaller selon la procédure que Zaurux m'a gentiment indiquée en même temps que celle de l'installation, mais bon, vu que ça marche comme ça, effectivement....

[funkyalf]

(06-10-2019, 01:14 PM)Bigga a écrit :

(06-10-2019, 12:49 PM)funkyalf a écrit : comme squeezelite fait appel à ALSA ça doit être lui qui doit choisir le format en 32 bits...
be correspond au codage big endian et le à little endian.
en big endian le bit de poids fort est en premier et en little endian c'est le bit de poids faible.
pour pouvoir s'adapter à toutes les interfaces externes je pense qu'on peut changer la représentation.

pour les paramètres alsa utilisé pour alsa

Citation : -a <params>
             Specify parameters used when opening an audio output device.  For ALSA, the  format
             <b>:<p>:<f>:<m>  is  used where <b> is the buffer time in milliseconds (values less
             than 500) or size in bytes (default 40ms); <p> is the  period  count  (values  less
             than  50)  or size in bytes (default 4 periods); <f> is the sample format (possible
             values: 16, 24, 24_3 or 32); <m> is whether to use mmap (possible values: 0 or  1).

les valeurs que tu as dans ton ficher sont en bytes, tu peux jouer sur les paramètres pour voir si ça change quelque chose.
mais je dirais si ça marche touche à rien.

quand à optimiser le son je suppose que tu parles de l'écoute ?
je ne vois rien à installer de mon côté

Oui, je parlais d'écoute.
Tu as répondu précisément à mes interrogations.
Je compte bien suivre ton conseil avisé, ne rien faire puisque ça marche, mais du coup tes infos me posent questions sur mes paramètres ALSA:

-D -a 4096:8096:32:0 -C 5 -n

D'après ce que je comprends de tes explications, chez moi: "b" (buffer time) est à 4096 et "p" (period count) est à 8096, or d'après ton message ils devraient être respectivement en dessous de 500 et de 40 ms. Comment expliquer cela? Est ce que l'unité est différente chez moi? Comment le savoir?

les deux paramètres buffer et periode peuvent être exprimés en ms ou bytes ...
il n'y a pas besoin de préciser l'unité, elle va être déterminé suivant la valeur

pour le buffer en dessous de 500 elle est en milli secondes
au dessus elle est en bytes

pour la periode c'est pareil en dessous de 50 elle est en ms au dessus en bytes
donc dans ta configuration elle sont en bytes

(06-10-2019, 01:14 PM)Bigga a écrit :

---

J'ai installé, sur les conseils de Zaurux, récemment, un script d'optimisation audio sous Linux (Qui est censé optimiser l'utilisation du CPU pou l'audio):

Automated Install
Code :
curl -sSL https://github.com/dynobot/Linux-Audio-A...install.sh | bash


Automated Removal
Code :
curl -sSL https://github.com/dynobot/Linux-Audio-A.../remove.sh | bash

Peut être est-ce cela qui a changé certains paramètres?
En toute honnêteté, je n'ai pas remarqué de mieux ni de moins bien au niveau sonore avec ce script chez moi. Je pourrais le désinstaller selon la procédure que Zaurux m'a gentiment indiquée en même temps que celle de l'installation, mais bon, vu que ça marche comme ça, effectivement....

nope le script joue seulement sur les priorités et fait un truc sur la latence du reseau (que je ne suis pas sur de capter) et il va chercher un autre script qui va jour sur la latence du kernel...
si je me souviens bien sur audio linux ça marche avec un kernel real time.
donc je dirais sur une installation de dietpi le script n'aura aucun effet
et ça ne touche pas ni squeezelite ou alsa

pour avoir jouer à une époque avec un linux rt sur une cubox et essayer de modifier les paramètres/priorités...
ça n'a que peu d'influence

mais ce ne sont que mes expériences et mes opinions personnelles

[Bigga]

Merci de ces précisions.
Ton opinion à ce sujet, y compris au niveau auditif, est intéressante, car tu comprends ce qui se passe au niveau informatique, et du coup ta réflexion en cas d'impression de modification peut être amenée à aller chercher plus loin.
En l'occurence, je n'ai pas perçu de modifications à l'oreille non plus.
Encore merci de tes lumières en tous cas!

[volpone75]

(06-09-2019, 03:25 PM)Bigga a écrit : ....
Bon... J'avais le souvenir d'avoir essayé des fichiers DSD de test (Pris sur Native DSD) et que mon DAC RME ADI 2 DAC reconnaissait bien le flux DSD 64 ou 128 (Au dessus pas possible du fait d'une limitation sous Squeezelite). Mais n'ayant pas écouté ces fichiers depuis quelques mois (Je n'ai pas pour l'instant acheté d'albums en DSD, ni rippé mes quelques SACD, n'ayant pas de lecteur le permettant), j'ai préféré vérifier.
Eh bien tout fonctionne: le DAC indique bien le flux DSD, le bon taux, et la gestion numérique du volume est désactivée du coup, ce qui est logique en DSD natif ou DoP.
J'avoue ne pas bien comprendre du coup à quoi correspond le réglage "disabled" dans l'Allo Web GUI, qui était dans ma mémoire supposé entrainer un transcodage du DSD en PCM.
Volpone75, tu as une explication sur ce mystère? Ai-je rompu à l'époque la coordination entre l'Allo Web GUI et Squeezelite en réalisant des réglages en ligne de commande grâce à votre aide à toi et quelques autres? J'aimerais juste comprendre, car sinon ça fonctionne donc pas de souci.
A noter sinon que depuis mes déboires avec le DSD il y a quelques mois, Dietpi a rajouté une option "DoP" en plus des options u32be, u32le, etc...

Hello, si je me souviens bien:
- Le DAC RME fonctionne exclusivement en DoP (pas en "natif").
- Il faut donc sélectionner "DoP" dans ALLO Web GUI (ce qui n'était auparavant pas possible car il y avait un bug. u32le/u32be ne servent qu'en "natif" et donc à rien dans ton cas)
- Apparemment la version 1.8.7 de SqueezeLite utilisée actuellement dans DietPi est limitée au DSD128, le 256 ne passe pas.
- Pour afficher la ligne de commande de lancement de SqueezeLite "en cours" (ALLO Web GUI évite d'avoir à éditer les commandes de lancement manuellement mais n'a aucune autre action) :

En "Disabled" (PCM, pas de paramètre -D)

Code :

root@USBridge:~# more /etc/systemd/system/squeezelite.service
[Unit]
Description=squeezelite

[Service]
Type=simple
ExecStart=/usr/bin/squeezelite -a 4096:8096:32:0 -C 5 -n 'DietPi-Squeezelite' -f /var/log/squeezelite.log

[Install]
WantedBy=multi-user.target

En DoP (paramètre -D :dop, il est possible que -D sans :dop fonctionne aussi car c'est l'option par défaut)

Code :

root@USBridge:~# more /etc/systemd/system/squeezelite.service
[Unit]
Description=squeezelite

[Service]
Type=simple
ExecStart=/usr/bin/squeezelite -a 4096:8096:32:0 -C 5 -n 'DietPi-Squeezelite' -f /var/log/squeezelite.log -D :dop

[Install]
WantedBy=multi-user.target

En Natif (paramètre -D :u32be big endian, par exemple mais ne fonctionne pas avec le DAC ADI 2)

Code :

root@USBridge:~# more /etc/systemd/system/squeezelite.service
[Unit]
Description=squeezelite

[Service]
Type=simple
ExecStart=/usr/bin/squeezelite -a 4096:8096:32:0 -C 5 -n 'DietPi-Squeezelite' -f /var/log/squeezelite.log -D :u32be

[Install]
WantedBy=multi-user.target

- Pour le script d'optimisation j'ai le même avis que @funkyalf

[Bigga]

Oui, Volpone75, quand on voit les réglages chez moi sur Squeezelite, DoP n’est pas précisé (Seul -D est noté) et pourtant ça fonctionne.
Donc soit DoP marche aussi avec seulement -D, comme tu le suggères, soit Le RME ADI 2 DAC reçoit du DSD natif, ce qui est possible vu qu’il possède un mode dédié normalement, mais qui, il me semble, était incompatible avec Linux en DSD natif.
Il faudrait que je repotasse le mode d’emploi du DAC pour savoir comment on peut discriminer le DSD natif du DoP (Je veux dire techniquement sur le DAC). Je vous tiendrai au courant.

[volpone75]

(06-10-2019, 06:53 PM)Bigga a écrit : Oui, Volpone75, quand on voit les réglages chez moi sur Squeezelite, DoP n’est pas précisé (Seul -D est noté) et pourtant ça fonctionne.
Donc soit DoP marche aussi avec seulement -D, comme tu le suggères, soit Le RME ADI 2 DAC reçoit du DSD natif, ce qui est possible vu qu’il possède un mode dédié normalement, mais qui, il me semble, était incompatible avec Linux en DSD natif.
Il faudrait que je repotasse le mode d’emploi du DAC pour savoir comment on peut discriminer le DSD natif du DoP (Je veux dire techniquement sur le DAC). Je vous tiendrai au courant.

J'ai vérifié auprès de RME que le ADI 2 ne fonctionne qu'en DoP. Donc c'est simplement que -D et -D :dop sont équivalents dans la ligne de commande.

Pour le natif il faudrait -D :u32le ou :u32be mais dans ce cas rien de bon ne sortira de ton DAC. Le mode "DSD direct" du  ADI2 est sans doute un mode qui désactive le contrôle de volume et les autres fonctions DSP... mais encore une fois en DoP c'est bien du DSD que ton DAC reçoit et convertit au final. Le seul point à vérifier est la compatibilité DSD 256 qui est effective avec ROON et HQPlayer mais pas avec SqueezeLite 1.8.7.

[Bigga]

(06-10-2019, 07:01 PM)volpone75 a écrit :

(06-10-2019, 06:53 PM)Bigga a écrit : Oui, Volpone75, quand on voit les réglages chez moi sur Squeezelite, DoP n’est pas précisé (Seul -D est noté) et pourtant ça fonctionne.
Donc soit DoP marche aussi avec seulement -D, comme tu le suggères, soit Le RME ADI 2 DAC reçoit du DSD natif, ce qui est possible vu qu’il possède un mode dédié normalement, mais qui, il me semble, était incompatible avec Linux en DSD natif.
Il faudrait que je repotasse le mode d’emploi du DAC pour savoir comment on peut discriminer le DSD natif du DoP (Je veux dire techniquement sur le DAC). Je vous tiendrai au courant.

J'ai vérifié auprès de RME que le ADI 2 ne fonctionne qu'en DoP. Donc c'est simplement que -D et -D :dop sont équivalents dans la ligne de commande.

Pour le natif il faudrait -D :u32le ou :u32be mais dans ce cas rien de bon ne sortira de ton DAC. Le mode "DSD direct" du  ADI2 est sans doute un mode qui désactive le contrôle de volume et les autres fonctions DSP... mais encore une fois en DoP c'est bien du DSD que ton DAC reçoit et convertit au final. Le seul point à vérifier est la compatibilité DSD 256 qui est effective avec ROON et HQPlayer mais pas avec SqueezeLite 1.8.7.

En fait, après relecture et essais sur mon RME ADI 2 DAC, j'interprète les choses d'une manière un peu différentes. C'est vrai que le mode d'emploi n'est pas très clair à ce niveau:



En mode DSD standard, je lance un fichier DSD, le DAC me dit ce qu'il voit comme fichier en entrée, mais le contrôle du volume reste actif.
En mode DSD direct, c'est très différent: je lance un fichier DSD, le DAC me dit ce qu'il voit en entrée comme fichier, mais le contrôle du volume est inactivé et le volume est automatiquement fixé à -3,5dB (Attention à bien baisser le volume de l'ampli analogique derrière si il y en a un, sinon ça peut faire un peu mal aux oreilles).
Ce que je comprends, au vu de ce qui se passe sur mon DAC et de ce que RME t'a dit, Volpone75, c'est que le mode DSD direct concerne le DoP, et bypasse le DSP.
Ce qui est appelé mode DSD standard est un mode DSD converti en PCM, donc qui permet de décrypter un flux DSD en entrée mais qui le transforme ensuite en PCM pour bénéficier du DSP.
Au début, quand j'ai parcouru le mode d'emploi du DAC, j'avais compris que le mode DSD standard était un mode DoP, dans lequel le DAC utilisait les 8 bits du header signal pour jouer sur le volume. Je pensais donc que le mode DSD direct était un mode DSD natif. Mais si RME te confirme que l'ADI 2 DAC ne lit que le DSD en DoP (C'est quand même simple à écrire en gras sur un mode d'emploi, je comprends pas pourquoi c'est pas clarifié au début du chapitre sur le DSD), le mode DSD direct ne peut correspondre qu'à du DoP.

[volpone75]

(06-10-2019, 08:30 PM)Bigga a écrit : ...
En mode DSD standard, je lance un fichier DSD, le DAC me dit ce qu'il voit comme fichier en entrée, mais le contrôle du volume reste actif.
En mode DSD direct, c'est très différent: je lance un fichier DSD, le DAC me dit ce qu'il voit en entrée comme fichier, mais le contrôle du volume est inactivé et le volume est automatiquement fixé à -3,5dB (Attention à bien baisser le volume de l'ampli analogique derrière si il y en a un, sinon ça peut faire un peu mal aux oreilles).
Ce que je comprends, au vu de ce qui se passe sur mon DAC et de ce que RME t'a dit, Volpone75, c'est que le mode DSD direct concerne le DoP, et bypasse le DSP.
Ce qui est appelé mode DSD standard est un mode DSD converti en PCM, donc qui permet de décrypter un flux DSD en entrée mais qui le transforme ensuite en PCM pour bénéficier du DSP.
Au début, quand j'ai parcouru le mode d'emploi du DAC, j'avais compris que le mode DSD standard était un mode DoP, dans lequel le DAC utilisait les 8 bits du header signal pour jouer sur le volume. Je pensais donc que le mode DSD direct était un mode DSD natif. Mais si RME te confirme que l'ADI 2 DAC ne lit que le DSD en DoP (C'est quand même simple à écrire en gras sur un mode d'emploi, je comprends pas pourquoi c'est pas clarifié au début du chapitre sur le DSD), le mode DSD direct ne peut correspondre qu'à du DoP.

On est d'accord. Le seul "pur" mode DSD de ton DAC est le "DSD direct".
Si le DSD est converti en PCM par l'électronique du DAC (mode DSD "standard") ce n'est plus du DSD 1 bit et le chemin du signal est moins "pur". 

Reste à savoir si la différence est audible ? En tous cas le grand apôtre du DSD qu'est Jussi Laako ne jure que par l'ADI2 en mode DSD direct (avec HQPlayer en amont évidemment). On s'éloigne de l'USBridge qui n'intervient pas et est capable de transporter en "natif" comme en DoP, ensuite c'est le boulot du DAC.

[Bigga]

(06-10-2019, 08:39 PM)volpone75 a écrit :

(06-10-2019, 08:30 PM)Bigga a écrit : ...
En mode DSD standard, je lance un fichier DSD, le DAC me dit ce qu'il voit comme fichier en entrée, mais le contrôle du volume reste actif.
En mode DSD direct, c'est très différent: je lance un fichier DSD, le DAC me dit ce qu'il voit en entrée comme fichier, mais le contrôle du volume est inactivé et le volume est automatiquement fixé à -3,5dB (Attention à bien baisser le volume de l'ampli analogique derrière si il y en a un, sinon ça peut faire un peu mal aux oreilles).
Ce que je comprends, au vu de ce qui se passe sur mon DAC et de ce que RME t'a dit, Volpone75, c'est que le mode DSD direct concerne le DoP, et bypasse le DSP.
Ce qui est appelé mode DSD standard est un mode DSD converti en PCM, donc qui permet de décrypter un flux DSD en entrée mais qui le transforme ensuite en PCM pour bénéficier du DSP.
Au début, quand j'ai parcouru le mode d'emploi du DAC, j'avais compris que le mode DSD standard était un mode DoP, dans lequel le DAC utilisait les 8 bits du header signal pour jouer sur le volume. Je pensais donc que le mode DSD direct était un mode DSD natif. Mais si RME te confirme que l'ADI 2 DAC ne lit que le DSD en DoP (C'est quand même simple à écrire en gras sur un mode d'emploi, je comprends pas pourquoi c'est pas clarifié au début du chapitre sur le DSD), le mode DSD direct ne peut correspondre qu'à du DoP.

On est d'accord. Le seul "pur" mode DSD de ton DAC est le "DSD direct".
Si le DSD est converti en PCM par l'électronique du DAC (mode DSD "standard") ce n'est plus du DSD 1 bit et le chemin du signal est moins "pur". 

Reste à savoir si la différence est audible ? En tous cas le grand apôtre du DSD qu'est Jussi Laako ne jure que par l'ADI2 en mode DSD direct (avec HQPlayer en amont évidemment). On s'éloigne de l'USBridge qui n'intervient pas et est capable de transporter en "natif" comme en DoP, ensuite c'est le boulot du DAC.

Ça c’est la question à 1000 francs! Peut être est ce surtout important au moment de la conversion selon le DAC qu’on possède: certains fonctionnent mieux en DSD, d’autres en PCM. Un upsampling en amont suffit dans ce cas. Mais peut être est ce lié au format de fichier lui même... On trouve des avis divergents à ce sujet, y compris chez les pro, comme tu le soulignes. Personnellement, je n’ai écouté que des fichiers test, j’ai pas vraiment d’avis tranché.
Je ne me suis pas trop intéressé à HQPlayer/NAA pour l’instant, car j’ai cru comprendre que l’interface et l’indexation des fichiers n’etaient pas des plus agréables, enfin sans Roon en tous cas. Je suis trop attaché à une navigation de type LMS pour l’instant.