(04-06-2017, 11:35 AM)Bear a écrit :(04-05-2017, 10:13 PM)volpone75 a écrit : Je n'ai pas bien compris pourquoi il fallait s'affranchir du switch. C'est une optimisation sans doute mais à mon avis pas prioritaire. Je vois ça comme une complication mais si tu constates des apports à l'usage je reverrais ma position.
Bonjour Volpone,
Plusieurs contributeurs sur devialetchat.com ou computeraudiophile.com ont constaté que cela apportait davantage de transparence. Les raisons possibles invoquées sont la piètre qualité de l'alimentation et de l'horloge du switch. C'est de la même veine que les constatations qui montrent qu'un W4S Recovery améliore la qualité du son en entrée USB asynchrone d'un DAC. Difficile à comprendre, mais observable.
Bonjour @Bear. Compris ...
La problématique du débit Ethernet en DSD512 pour le NAA Linux est à mon avis complètement distincte.
J’avoue que sur le mode « bridge » je n’ai pas d’a priori favorable et voyais cela comme du « ceinture et bretelles » à effet marginal. Si les équipements réseau altéraient les données transmises notre monde s’écroulerait rapidement.
Demeurent peut être en audio les pollutions RFI générées par le switch et pouvant transiter sur les conducteurs avec d’éventuels effets sur le NAA et/ou le DAC: Augmentation du niveau de bruit et donc diminution de la "transparence" ?
Si l’on considère que le DAC n’est pas assez soigné en terme d’immunité aux pollutions EMI / RFI j’opterai plutôt pour du filtrage / isolation juste avant le convertisseur..
Mais je suis pragmatique quand même. Si à l’usage, vous entendiez une amélioration significative en mode bridge j’essaierai bien sur le truc dans la mesure ou cela ne peut pas faire de mal et économise un filtre et si cela ne fragilise pas … Donc merci à @paulw, toujours efficace, pour la procédure Linux !
(04-07-2017, 08:04 AM)Bear a écrit :(04-07-2017, 01:20 AM)Pascal64 a écrit : Tinysqueze passe par la RAM.
Je n'ai pas bcp d'expérience avec ce truc sous Linux car ne l'ai pas essayé longtemps en tant que player.
En revanche je sais une chose : c'était ultra rapide et nous n'avions eu aucun mal à faire tourner les gros fichiers de convolution en 192khz chez Dom.
C'était juste une idée (de novice) en passant.
Bonjour Pascal,
L'idée est sans doute intéressante si on veut rester en PCM. Mais la condition à prendre en compte pour optimiser l'utilisation de ce DAC est d'upsampler en DSD. Et là, je pense que Tinysqueeze va s'avérer un peu inadapté
Certes …
Mais pour rebondir sur la remarque de @Pascal64, intéressant aussi de voir ce que donne le DAC8 DSD (ou d’autres DAC du même genre) alimenté via des configurations plus simples et répandues même si ce n’est pas le «top » de ce qu’il peut donner.
Je trouve que c’est déjà très bon en DSD128 et jouable sans aucun problème via un NUC I5 basic. Au niveau soft je ferai des essais avec Roon sans HQP dans la boucle. Jriver, Audirvana et d’autres logiciels ont aussi des capacités d’upsampling et conversion DSD à essayer.
On est bien sur tenté, moi le premier, d’aller chercher le maximum. Pour cela HQPlayer et un serveur puissant sont je pense nécessaire.
ROON > HQPlayer > Allo-USBridge (DietPi) > T+A DAC8 DSD > NAD M22 (Ncore Hypex) > Harbeth SLH5+
Schéma installation
Schéma installation