stringerbell a écrit :
le fait que le protocole soit bitperfect est une condition nécessaire mais pas suffisante comme on dit en mathématiques, parce que ça fait fi du coût d'implémentation intrinsèque du dudit protocole sur le endpoint. En gros si le dit protocole demande des ressources plus importantes ou génère une activité plus importante qu'un autre protocole. Aussi bien implémenté qu'il soit , ce protocole aura un impact négatif sur la qualité de restitution endpoint, et pourrait entraîner des différences sonores.
Salut Simon,
Là nous sommes bien d’accord. C’est bien l’implémentation du couple protocol et client qui fait la différence.
Néanmoins la demande en ressources système ne devrait pas varier de façon significative d’un protocole à l’autre.
Quelque que soit le produit (dCS, SONORE, etc.) tous fonctionnent de la même façon : un système embarqué qui gère le matériel et une pile IP. Sur cette pile IP se grefferont les protocoles comme UPnP, RAAT ou autres.. Ensuite de petits clients UPnP, RAAT, ou autres, exploiteront ces protocoles.
Si tout ça est correctement développé, la quantité de ressources utilisées par tel ou tel client ne devrait que peu varier. Donc le bruit électronique induit ne devrait également que peu varier.
Mais bien sûr on peut imaginer que UPnP est très bien intégré et que RAAT soit un ajout pas très optimisé. Dans ce cas, il est clair que le second pourrait se comporter comme une usine à gaz comparativement au premier.
Dans le cas de dCS, qui est un produit d’excellente qualité, je suis étonné que tu entendes des différences entre UPnP et RAAT par exemple (je pars du principe que ta musique est en local, sur ton réseau).
stringerbell a écrit :
Accessoirement c'est ce que je constate sur mon dcs network bridge où la seule variable est le protocole de transfert ( et que d'autres ont constaté). Ce que je déduis de ta réponse c'est que tu n'as fait de comparaisons. Et au final ce que tu dis c'est que ton système te convient, ce qui est l'essentiel
.
Dommage ça nous aurait de savoir ce que vaut un iphone en tant que transport, mais sans point de comparaison c'est délicat. le fait d'être sur batterie, pemet de fonctionner avec un courant plus propre, mais n'est pas une garantie, que le résultat final soit propre...
Si,si, j’ai, bien entendu, fait des comparaisons. Mais je n’en ai pas parlé car ce n’était pas mon propos et que je trouve que cela n’a pas de sens dans la mesure où j’ai utilisé un ordinateur connecté à l’Audiophilleo. Et comme tu le sais un ordinateur est le summum de la pollution pour un système HiFi. Bien sûr l’Adiophilleo est conçu pour faire l’interface entre une vilaine connection USB et le DAC, mais tout de même…
Voilà néanmoins ce que j’ai fait. Mes premiers essais si on peut dire.
J’ai utilisé un PC avec Windows 2016 Server que j’ai strippé au maximum pour que le système génère le moins de bruit possible. Je l’ai utilisé « head less », c’est-à-dire sans interface graphique. J’ai testé JRiver avec de la musique en local, puis j’ai testé JRiver en tant que client UPnP (fichiers sur NAS Synology + MinimServer) et enfin la machine a servi de Roon Endpoint.
Dans tous les cas c’était pas mal. J’ai cru entendre des différences ici et là, mais rien de vraiment significatif. Est-ce que j’aurais entendu une différence en faisant un test à l’aveugle ? J’en doute.
Plus tard j’ai fait le test avec le iPhone. Et là, la différence était claire.
Concernant le iPhone en tant que transport… c’est faire un gros raccourci. C’est bel et bien l’ensemble Audiophilleo conjointement au iPhone qui forment un transport, au même titre qu’un SONORE ou un dCS.
Le iPhone reçoit le flux et le transmet à l’Audiophilleo qui va reclocker tout ça et isoler le DAC du iPhone (vu le peu de bruit que génère le iPhone, l’isolation sera top). La signature sonore sera alors celle de l’Audiophilleo et non de l’iPhone.
.L'iphone est donc une option plus qu'intéressante. Pour les différences
