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

[Bigga]

(01-02-2019, 09:59 PM)volpone75 a écrit :

(01-02-2019, 07:19 PM)Bigga a écrit :

---

Bon, j'ai redémarré via Allo Web Gui et réglé la commande -D dans le fichier en question qui est de nouveau rempli. Et au moins il y a du son, ouf!
Mais ce n'est pas tout... Le DSD (En DoP donc) est lu sans plantage! Enfin pour le DSD64 et le DSD128. Le DSD256 fait un bruit de cigale, rien d'autre. Mais pas de plantage, je peux néanmoins reprendre la lecture d'un autre fichier sans souci.
Donc, pour résumer, attention au DAC et sa compatibilité avec le kernel de Dietpi, déjà, et sinon, attention au bug de l'Allo Web GUI concernant le DoP. Il faut rajouter le paramètre -D manuellement dans le fichier correspondant en se connectant à Dietpi en ssh. C'est pas très compliqué, bien moins que d'arriver à comprendre où était le souci.
Merci en tous cas à tous ceux qui m'ont aidé à comprendre, et en particulier Volpone75 qui s'est repenché sur LMS pour cela.
Pour le DSD256, mystère...

J'ai remonté le bug DoP / Allo Web Gui à DietPi: https://github.com/Fourdee/DietPi/issues/2386

En général ils sont réactifs et proposent chaque mois une mise à jour du système (évolutions et correctifs qui concernent beaucoup de domaines et pas spécifiquement l'audio). En attendant la correction du bug DoP si tu n'utilises pas l'interface WEB de configuration SqueezeLite cela devrait continuer à fonctionner même après un reboot. De toute façon dorénavant tu connais la chanson ....

En ce qui concerne le Kernel Linux utilisé par l'USBridge il est lui aussi régulièrement "patché" par ALLO et DietPi pour prendre en compte les DAC avec capacités de transport DSD "nartif" sous LINUX. La réactivité dans la maintenance et les évolutions sont d'ailleurs pour moi un des points forts de DietPi. Sonore et SOtM (les concurrents de l'USBridge) ne font à mon avis pas mieux et plutôt moins bien sur ce plan ...

En ce qui concerne le DSD256 il faudra investiguer. Soit cela vient de SqueezeLite qui ne sait pas encapsuler le DSD256 en PCM 768 kHz, soit c'est une limitation au niveau du DAC en DoP (ou moins probablement un réglage). Dans le principe un DAC passant du 768 kHz a la capacité de faire du DSD256 en DoP. Essayes de te renseigner sur le forum RME ainsi que sur les capacités de SqueezeLite et tiens nous au courant.

Quoi qu'il en soit tu devrais enfin pourvoir commencer à profiter de ton DAC RME, et surtout apprécier, ou pas, le "son DSD" sachant que les enregistrements en DSD256 sont rares mais qu'en 128 tu auras plus de choix et déjà une qualité DSD représentative.

Oui c’est déjà une bonne avancée!
Je me renseignerai sur le RME, car effectivement cela me semble bizarre qu’il ne passe pas le DoP en 256.
Si cela vient de Squeezelite, je pense ne pas être à la hauteur pour me renseigner sur le forum dietpi ou slimdevices, vu le côté abscons des réponses la plupart du temps.

[Bigga]

Bon, après quelques renseignements auprès de RME, et à leur demande, j'ai upsamplé un fichier DXD en 768 kHz (Donc du PCM 24 bits 768 kHz), et apparemment c'est LMS ou Squeezelite qui ne gère pas cet échantillonnage, iPeng m'affiche un message d'erreur "ce taux d'échantillonnage n'est pas pris en charge".

[ajls]

hello 
il me semble que tu ne peux pas aller au delà de 384 avec squeezelite.
mais pas sûr, à confirmer sur le forum slimdevices

edit: en tous cas, peut être qu'avec cette version de squeezelite ce n'est pas ok

[Bigga]

(01-07-2019, 10:21 PM)ajls a écrit : hello 
il me semble que tu ne peux pas aller au delà de 384 avec squeezelite.
mais pas sûr, à confirmer sur le forum slimdevices

edit: en tous cas, peut être qu'avec cette version de squeezelite ce n'est pas ok

C'est ce que j'ai expérimenté. 384 ça passe en PCM (ou DoP), mais pas au dessus. Une limitation de Squeezelite. Peut-être sera-t-elle abolie un de ces quatre.
En tous cas, en ce concerne la lecture DSD en DoP, cela "limite" à du 128.

[volpone75]

(01-07-2019, 11:33 PM)Bigga a écrit :

(01-07-2019, 10:21 PM)ajls a écrit : hello 
il me semble que tu ne peux pas aller au delà de 384 avec squeezelite.
mais pas sûr, à confirmer sur le forum slimdevices

edit: en tous cas, peut être qu'avec cette version de squeezelite ce n'est pas ok

C'est ce que j'ai expérimenté. 384 ça passe en PCM (ou DoP), mais pas au dessus. Une limitation de Squeezelite. Peut-être sera-t-elle abolie un de ces quatre.
En tous cas, en ce concerne la lecture DSD en DoP, cela "limite" à du 128.

Pour le DoP en 256 j'ai l'impression que c'est finalement peut-être plus une limitation matérielle / logicielle de la bande passante induite par les SBC ARM (RPI, SPARKY etc ...) que par LMS / SqueezeLite quoique effectivement ce ne soit pas la toute dernière version de SqueezeLite datant de fin 2018 qui est proposée par DietPi 1.9.0-1021 vs 1.8.7-1020.

Du coup la problématique du transport natif redevient d'actualité si tu veux, très légitimement, tester le son DSD256 avec l'USBridge. Peut être demander à RME s'ils ont des exemples de plateforme LINUX qui fonctionnent avec leur DAC en DSD256 natif (ou même en DoP) et s'en inspirer. En désespoir de cause essayer via un PC ou un MAC. Ce qui est certain est que le natif nécessite deux fois moins de bande passante que l'encapsulation DoP.

Sur ce sujet: https://soundcheck-audio.blogspot.com/20...6-dsd.html

Par ailleurs et au delà de ces questions technico-techniques as-tu pu écouter de bons enregistrements DSD128 et comment sonne le RME dans ce mode ? A mon avis c'est très proche du DSD256 sachant une fois encore qu'il y a vraiment très peu de DSD256 sur le marché. Le vrai "gap" est PCM / DSD avec un DAC performant en DSD comme semble l'être ton RME (le DSD64 est néanmoins un peu juste).

[Bigga]

(01-08-2019, 12:25 AM)volpone75 a écrit :

(01-07-2019, 11:33 PM)Bigga a écrit :

(01-07-2019, 10:21 PM)ajls a écrit : hello 
il me semble que tu ne peux pas aller au delà de 384 avec squeezelite.
mais pas sûr, à confirmer sur le forum slimdevices

edit: en tous cas, peut être qu'avec cette version de squeezelite ce n'est pas ok

C'est ce que j'ai expérimenté. 384 ça passe en PCM (ou DoP), mais pas au dessus. Une limitation de Squeezelite. Peut-être sera-t-elle abolie un de ces quatre.
En tous cas, en ce concerne la lecture DSD en DoP, cela "limite" à du 128.

Pour le DoP en 256 j'ai l'impression que c'est finalement peut-être plus une limitation matérielle / logicielle de la bande passante induite par les SBC ARM (RPI, SPARKY etc ...) que par LMS / SqueezeLite quoique effectivement ce ne soit pas la toute dernière version de SqueezeLite datant de fin 2018 qui est proposée par DietPi 1.9.0-1021 vs 1.8.7-1020.

Du coup la problématique du transport natif redevient d'actualité si tu veux, très légitimement, tester le son DSD256 avec l'USBridge. Peut être demander à RME s'ils ont des exemples de plateforme LINUX qui fonctionnent avec leur DAC en DSD256 natif (ou même en DoP) et s'en inspirer. En désespoir de cause essayer via un PC ou un MAC. Ce qui est certain est que le natif nécessite deux fois moins de bande passante que l'encapsulation DoP.

Sur ce sujet: https://soundcheck-audio.blogspot.com/20...6-dsd.html

Par ailleurs et au delà de ces questions technico-techniques as-tu pu écouter de bons enregistrements DSD128 et comment sonne le RME dans ce mode ? A mon avis c'est très proche du DSD256 sachant une fois encore qu'il y a vraiment très peu de DSD256 sur le marché. Le vrai "gap" est PCM / DSD avec un DAC performant en DSD comme semble l'être ton RME (le DSD64 est néanmoins un peu juste).

Vu le message d’erreur dans iPeng, je crois quand même que la versions Squeezelite de Dietpi ne permet pas l’échantillonnage nécessaire au DoP256. Après qu’il y ait une limitation hardware aussi, c’est possible.
Bon, pour le DSD natif je verrai en paramétrant manuellement le fichier où se trouve -D. Pour l’heure je vais essayer d’ecouter les éventuels gains sonores du DoP128, parce que je n’ai pas eu beaucoup le temps de me concentrer sur l’ecoute avec tous ces déboires.
Je vous dirai ce que j’en pense.

[volpone75]

(01-08-2019, 12:45 AM)Bigga a écrit : ...
Bon, pour le DSD natif je verrai en paramétrant manuellement le fichier où se trouve -D. Pour l’heure je vais essayer d’ecouter les éventuels gains sonores du DoP128, parce que je n’ai pas eu beaucoup le temps de me concentrer sur l’ecoute avec tous ces déboires.
Je vous dirai ce que j’en pense.

En ce qui concerne le 768 kHz nécessaire au DoP: Si la limitation vient des capacités de la plateforme (hard ou soft), c'est logique que SqueezeLite renvoie une erreur. Si la limitation vient du programme SqueezeLite lui même il y a plus de chances que tu puisses trouver une version qui va bien, mais j'en doute.

Pour le paramétrage de la sortie de SqueezeLite en DSD natif cela doit être un truc du genre -D :u32be ou u32le (il faut couper et relancer dans ALLO Web GUI à chaque essai).

Ceci dit il me semble que tu as déjà beaucoup essayé sans succès le natif au départ et a priori dans ce mode pas de bug de l'interface ALLO, donc pas besoin d'éditer manuellement.

[ajls]

je suis d'accord avec Volpone bien sûr.
reste éventuellement la question de la version squeezelite.
la dernière 1.9 gère tout ça si j'ai bien lu. il ne me semble pas qu'il y ait de limitation matérielle tant que l'on ne calcule rien.
franchement ça vaudrait le coup de poser la question sur slimdevices où il y a en direct des développeurs squeezelite plugins lms etc.

[Bigga]

(01-08-2019, 01:07 AM)volpone75 a écrit :

(01-08-2019, 12:45 AM)Bigga a écrit : ...
Bon, pour le DSD natif je verrai en paramétrant manuellement le fichier où se trouve -D. Pour l’heure je vais essayer d’ecouter les éventuels gains sonores du DoP128, parce que je n’ai pas eu beaucoup le temps de me concentrer sur l’ecoute avec tous ces déboires.
Je vous dirai ce que j’en pense.

En ce qui concerne le 768 kHz nécessaire au DoP: Si la limitation vient des capacités de la plateforme (hard ou soft), c'est logique que SqueezeLite renvoie une erreur. Si la limitation vient du programme SqueezeLite lui même il y a plus de chances que tu puisses trouver une version qui va bien, mais j'en doute.

Pour le paramétrage de la sortie de SqueezeLite en DSD natif cela doit être un truc du genre -D :u32be ou u32le (il faut couper et relancer dans ALLO Web GUI à chaque essai).

Ceci dit il me semble que tu as déjà beaucoup essayé sans succès le natif au départ et a priori dans ce mode pas de bug de l'interface ALLO, donc pas besoin d'éditer manuellement.

Chez moi le problème était que le fichier qui doit contenir -D ne contenait rien, pas même de -D :u32be ou le, et ce même si je réglais cela dans l'Allo Web Gui... Donc peut être que le bug s'étend à la gestion DSD au complet.
J'essaierai en réglant à la main, ce que je 'ai pas encore fait.

---

(01-08-2019, 04:01 PM)ajls a écrit : je suis d'accord avec Volpone bien sûr.
reste éventuellement la question de la version squeezelite.
la dernière 1.9 gère tout ça si j'ai bien lu. il ne me semble pas qu'il y ait de limitation matérielle tant que l'on ne calcule rien.
franchement ça vaudrait le coup de poser la question sur slimdevices où il y a en direct des développeurs squeezelite plugins lms etc.

Mais est-il possible de mettre à jour Sqeezelite vers cette version 1.9 depuis Dietpi?
Franchement, même si cela m'intéresse et me concerne, vu la teneur des forums du style Slimdevices ou GitHub, Dietpi, ou Computer Audiophile, je n'ai pas du tout les compétences pour poser des questions en essayant obtenir des réponses claires.
Si l'un d'entre vous se sent, je lui en saurais gré.

[Charon]

..I..