Roon, une nouvelle expérience utilisateur, qui a testé ?

[corintin]

sinon pour Roon d'autres avis et retours ?  

c'est du même genre... révolutionnaire !

tout le marché UPnP se trompe mais heureusement Roon est un être supérieur...  

Roon qui est à mon sens bien supérieure à toutes les solutions UPnP existantes car basée sur des principes techniques très différents.

[volpone]

La discussion qui avait tendance à un peu partir en vrille n'est finalement pas inintéressante car elle met en lumière des incompréhensions propices aux engueulades.

A titre d'exemple et pour faire le lien avec le sujet de ce fil je soumet un crobar basic de mon réseau Roon qui illustre la différence entre le flux réseau et les signaux audio numériques:

Roon (1).png

Je suis  donc d'accord avec @ndstael, @zeroundemi et @hollow en ce qui concerne la différence entre le flux réseau en amont du streamer (ou endpoint selon la terminologie) dans lequel tous les "paquets" de données sont transmis selon différents protocoles et le flux audio numérique en aval de celui-ci dans lequel ces "paquets" sont assemblés et traités pour fournir un signal PCM exploitable par le DAC sur ses entrées USB, AES ou S/PDIF.

Par ailleurs le fait que Roon n'utilise pas UPnP mais d'autres protocoles réseau ne change rien à l'affaire, la seule nuance est que le décodage du fichier (par exemple FLAC > PCM) ne se fait pas au niveau du recepteur audio (endpoint/player/renderer) mais par le serveur Roon Core qui tourne dans mon cas sur un NUC. Le réseau transmet les "paquets" de PCM  qui pour autant ne sont pas équivalents aux "vrais" signaux PCM en sortie du streamer endpoint audio.

Par ailleurs si je devais optimiser quelque chose avec un "pont optique" cela serait entre le switch et les endpoints audio pour les garantir d'éventuelles pollutions électriques transmises par la liaison filaire ethernet mais j'avoue que je ne suis pas convaincu et préfère compter sur des endpoints bien conçus. Ceci dit je comprends que ceux qui entendent la différence puissent être tentés.

Enfin je n'utilise le WIFI que pour les ordinateurs et évidemment les tablettes qui contrôlent car pour les flux de données audio la liaison filaire me semble beaucoup plus stable.

[locke]

sinon pour Roon d'autres avis et retours ?  :wink:

J'ai testé Roon il y a quelques temps en espérant qu'il propose un support du client réseau de HQPlayer, mais ce n'était malheureusement pas le cas à l'époque. J'ai testé à peu près toutes les fonctionnalités de Roon, et je n'ai franchement pas été emballé. Et puis, de mon point de vue en tous les cas, la licence "à vie" reste très chère pour un soft de ce type.

Je suis quand même un peu étonné de tout le buzz qui est fait autour de cette boite et de leur logiciel, surtout quand on voit le peu d'informations communiquées sur leur site. On retrouve un peu la même chose que pour la Regen, ou même HQPlayer (la pire interface de l'histoire du logiciel audio !). Je pense, mais c'est une hypothèse, que ce n'est pas étrangers au fait qu'il existe maintenant des sites comme computer audiophile ou les comportement moutonniers sont fréquents.

Tout le monde cherche le Graal du dématérialisé... à 100€. Aussi, dès qu'une possibilité à moins de 150€/200€ est proposée, et surtout validée par un "ponte", c'est l'euphorie totale. Et si on peut en acheter plusieurs, alors c'est encore mieux. Le cas des FDA en France en est un autre exemple, et d'ailleurs j'en ai un... c'est dire si c'est grave docteur !   Mais je crois que de plus en plus en ont deux, avec une Regen... voire deux Regen + une alim linéaire ultra silencieuse, voire deux... La c'est encore plus grave  

Mais ne vous inquiétez pas les gars, on va y arriver. Serrons nous les coudes  

[Bela Lugosi]

.................

[Hollow]

Si ton système est aussi pourri que cela, je préfère encore mon syno  avec ventilateurs

De rien.

a+

[ajls]

cela faisait longtemps que je n'avais pas vu un troll à la fois aussi pitoyable et culotté  
bravo bela.
ciao ?

[mkl]

On peut être ne pas être d'accord avec ce que dit Bela, pointer d'éventuelles erreurs, rigoler de ses lubies, mais sont comportement n'est pas vraiment celui d'un troll. Ou alors il y en a plein le forum.

[Bela Lugosi]

.................

[locke]

vous le faites exprès ?

Oui bien évidemment !

La thèse que tu cites ainsi que les documents sur ces phénomènes physiques sont très intéressants. J'imagine que c'est peut être parce que tu as lu "PWM noise" et que c'est une notion audio que tu penses que l'impact sur le son sera audible si un ventilo génère ce type de bruit dans un NAS qui est la source de fichiers son...

Peut être que ces phénomènes de bruit magnétique pourraient avoir des effets dans les DACs s'ils avaient des ventilateurs, car nous sommes la dans le domaine de l'électronique. Sincèrement, je ne suis pas assez calé en électronique pour évaluer si ce serait perceptible ou pas. Mais la thèse montre en effet que c'est possible électriquement et que ça peut se simuler.

Mais dans le cas d'un NAS, il communique généralement avec d'autres ordinateurs via un réseau tcp/ip, et nous parlons donc de machines qui s'échangent des informations via des algorithmes et des protocoles. C'est de l'informatique et non pas de l'électronique. Or, on peut écouter un très bon vinyle sur une platine d'entrée de gamme, mais ce ne sera jamais aussi bon qu'une excellente platine. En revanche, on peut programmer et faire fonctionner des algorithmes géniaux aussi bien sur des PC d'entrée de gamme que sur des super-ordinateurs.

Si on encodait un bruit de ventilo dans les trames, on s'en rendrait compte. Impossible de passer à côté... sauf si les protocoles et les algorithmes d'échange de fichier sont bâclés par des stagiaires qui font n'importe quoi...    Ce qui n'est pas le cas ici. Un des principes fondamentaux de l'informatique c'est justement que tu peux reproduire très exactement quelque chose si tu as le même algorithme et les mêmes données de bases ; que ton ordinateur ait un ventilateur ou pas, un processeur d'une marque ou d'une autre, une carte graphique géniale ou moins bonne, une alim pourrie ou super bruitée, etc... simplement la vitesse et les performances générales ne seront pas les mêmes. Mais tu obtiendras le même résultat (sauf simulation numérique chaotique , mais je pense que nous sommes assez loin de ce cas en audio...).

Dire cela ne veut pas dire qu'il n'y a pas de bruit électrique dans les câbles ethernet car il est en effet possible que ton câble transporte, en plus des trames qui sont elles "propres", du bruit électrique. Peut être en partie généré par le ventilo, des boucles de masse, des bruits électriques de toutes sortes,... on en a tous fait l'expérience et c'est super casse pied, d'ou l'idée du pont optique, voir même de la Regen. Mais tout cela n'a rien à voir avec le contenu transporté via le protocole réseau. Transporter du pétrole sur une mer propre ou sale, agitée ou calme, ne change pas la nature de la cargaison... sauf s'il sombre ou qu'il y a une fuite bien sur.

Enfin, rappelons nous que nos ordinateurs sont eux mêmes connectés au Net, ainsi que les NAS, eux mêmes connectés à des serveurs web, serveurs de données, serveurs de Google, de Facebook etc... et que ces serveurs ont tous des ventilos, dont le bruit j'imagine arriverait donc bien évidemment jusque dans nos trames de fichiers audio. Il serait quand même incroyable que l'informatique, au niveau international, reste aussi fiable avec autant de ventilos !

Pour le reste de tes conseils, je n'ai pas de commentaires particuliers, je pense que se sont des conseils de bon sens partagés par beaucoup. Mais pour les bruits de ventilo encodés dans les trames de fichiers flac transmis sur un cable ethernet alors la...

[corintin]

pas toujours très simple de suivre ces histoires de pont optique..

Si on se place du point de vue physique théorique, le pont optique ne sert absolument à rien.

Le pont optique que tout le monde encense est une solution intéressante techniquement mais cela reste une usine à gaz sur laquelle il est facile de faire des bêtises avec une mauvaise connexion d'un rj45 par exemple.

deux avis différents.. peut être ne l'a-t-il pas testé ??
pourtant l'expérience ne coûte pas très cher :
- deux TP-LINK MC110CS
- un câble fibre optique
le tout à 100€ chez LDLC ou autres

pour ceux que cela intéresse vraiment, le journaliste de HiFi News et
Gramophone, Andrew Everard, en parle sur son blog



"My latest music-network upgrade is another run of fibre-optic cabling – and it’s made an amazing difference"

cela a ensuite été popularisé via ComputerAudiophile et le Bleu notamment

[Bela Lugosi]

.....................

[corintin]

Et j'ai pris le temps de te répondre.

pas vu la réponse ! finalement, le pont optique, tu l'as testé ou pas testé chez toi ?

[Bela Lugosi]

Tiens donc...
Tu changes de ton?

T'es calmé?

[JérômeB]

Même si dans cette filière je dois avouer ne comprendre que les noms d'oiseaux que vous vous balancez à la figure, il serait souhaitable que le calme et le respect mutuel reprennent leurs droits.
Bordel de merde!

Merci d'avance.

[zeroundemi]

je ne comprends pas cette histoire de NAS qui extrait le flux audio et qui a une influence sur le son

Pourquoi un NAS n'enverait-il pas de flux audio ?

Il y a confusion au sujet du "flux audio" : en amont du Network player, il y a un logiciel qui tourne sur un NAS et envoie des fichiers par petits bouts (paquets de données), éventuellement séparés par des paquets de données destinés à d'autres appareils sur le réseau, et qui n'ont rien à voir avec l'audio

La transmission est cadencée par une horloge dont la fréquence ne change pas : le NAS peut envoyer "simultanément" un fichier audio  x 44.1 kHz à un appareil, un autre fichier x 48 kHz à un autre, une photo à l'imprimante, ..., sans que l'horloge du réseau ethernet change de fréquence




Un flux audio est envoyé d'un seul émetteur vers un seul récepteur (dac), par une liaison qui demeure établie pendant toute la durée de la transmission (pas de switch comme sur un réseau ethernet), il ne doit y avoir aucune coupure de la liaison. La transmission est cadencée par une horloge calée sur un multiple de la fréquence utilisée pour le fichier audio concerné, elle change de fréquence (*) chaque fois qu'on envoie un fichier dont la Fs est différente (44.1 / 48 / 96 / 192 kHz / DSD64 ...)


C'est ce qui fait toute la différence : dans les deux cas les données peuvent être exactes jusqu'au dernier bit (**)

Mais les aspects temporels [i](horloge, synchronisation émetteur/récepteur ...) ne sont pas du tout traités côté réseau ethernet, c'est le travail du "Network renderer" : il reçoit les paquets de données audio par petits bouts séparés à intervalles variables, à la cadence d'horloge du réseau ethernet, les stocke, les remet bout à bout sans coupures, éventuellement fait du transcodage, puis émet vers le dac sous forme de flux audio cadencé selon la Fs du fichier concerné



(*)  Simplification, inévitable vu le niveau des échanges qui ont précédé

(**) Ethernet transmet des données exactes ce qui n'est pas toujours le cas avec une liaison S/PDIF

si un ventilateur sous pwm d'un nas venait à modifier le transfert ethernet au sens data, c'est la révolution du 21ème siècle

Bravo ! Tu commences à comprendre à l'insu de ton plein gré : les perturbations ne passent pas au niveau data, car si c'était le cas le pont optique serait inutile  

[Patatorz]

La petite baffe a bien calmé tout le monde.
Sinon apparemment une mise à jour de l'auralic aries a amené le "Roon ready". Pour belcanto les séries black (dont le dernier intégré aci600) vont et rapidement compatibles. Pour le refstream apparemment il y aurait une modification hardware nécessaire pour le rendre Roon ready

[volpone]

Il y a confusion au sujet du "flux audio" : en amont du Network player ...

Merci @Zeroundemi pour ces explications limpides et pédagogiques, j'avais tenté le coup mais en étant sans doute trop "Roon oriented"  

Ce qui serait aussi intéressant est de pointer les quelques différences existant entre les différents protocoles applicatifs réseau, notamment UPnP, AirPlay, Roon (RAAT), LMS ...  

Ces protocoles fonctionnent bien sur selon le principe que tu exposes en ce qui concerne la différence flux réseau / flux audio et la fonction du bridge / streamer / renderer / player qui est principalement de transformer les paquets réseau en signaux audio numériques, mais il y a quelques nuances entre eux:

- Décodage du fichier audio par le "serveur" pour Roon et Airplay , par le recepteur/renderer pour UPnP.
- Clocking par le recepteur pour UPnP et Roon, pour Airplay j'ai l'impression que l'émetteur intervient mais je suis preneur de lumières la dessus.

[volpone]

La petite baffe a bien calmé tout le monde.
Sinon apparemment une mise à jour de l'auralic aries a amené le "Roon ready". Pour belcanto les séries black (dont le dernier intégré aci600) vont et rapidement compatibles. Pour le refstream apparemment il y aurait une modification hardware nécessaire pour le rendre Roon ready

Oui, dommage que l'intégré ACI600 coute 25 000$ car sinon cela m'aurait botté: Intégration des fonctions streamer, dac et amplification puissante dans un boitier unique assez discret avec des entrées analogiques dont un étage phono ... l'idéal !

Peut être que le M1 de Micromega qui est basé sur le même concept (sans doute en beaucoup moins bien et bon que le Bel Canto) mais ne coutera que 3000 ou 4000€ sera aussi "RoonReady". C'est dans l'esprit d'une solution intégrée simple à mettre en oeuvre et robuste.

[shal]

Il y a confusion au sujet du "flux audio" : en amont du Network player, il y a un logiciel qui tourne sur un NAS et envoie des fichiers par petits bouts (paquets de données), éventuellement séparés par des paquets de données destinés à d'autres appareils sur le réseau, et qui n'ont rien à voir avec l'audio

La transmission est cadencée par une horloge dont la fréquence ne change pas : le NAS peut envoyer "simultanément" un fichier audio  x 44.1 kHz à un appareil, un autre fichier x 48 kHz à un autre, une photo à l'imprimante, ..., sans que l'horloge du réseau ethernet change de fréquence




Un flux audio est envoyé d'un seul émetteur vers un seul récepteur (dac), par une liaison qui demeure établie pendant toute la durée de la transmission (pas de switch comme sur un réseau ethernet), il ne doit y avoir aucune coupure de la liaison. La transmission est cadencée par une horloge calée sur un multiple de la fréquence utilisée pour le fichier audio concerné, elle change de fréquence (*) chaque fois qu'on envoie un fichier dont la Fs est différente (44.1 / 48 / 96 / 192 kHz / DSD64 ...)


C'est ce qui fait toute la différence : dans les deux cas les données peuvent être exactes jusqu'au dernier bit (**)

Mais les aspects temporels [i](horloge, synchronisation émetteur/récepteur ...) ne sont pas du tout traités côté réseau ethernet, c'est le travail du "Network renderer" : il reçoit les paquets de données audio par petits bouts séparés à intervalles variables, à la cadence d'horloge du réseau ethernet, les stocke, les remet bout à bout sans coupures, éventuellement fait du transcodage, puis émet vers le dac sous forme de flux audio cadencé selon la Fs du fichier concerné



(*)  Simplification, inévitable vu le niveau des échanges qui ont précédé

(**) Ethernet transmet des données exactes ce qui n'est pas toujours le cas avec une liaison S/PDIF

Deux petites remarques.

Je veux bien de votre définition de flux audio mais attention elle n'est pas universelle . C'est une définition qui ne vaut que sur le Vert.

C'est ce que dit Hollow :

Disons que pour moi, un flux audio au premier sens du terme (comme en analogique) est un signal directement exploitable par un dac.
C'est tiré par les cheveux mais cela permet de différencier la nature des traitements.

Recherche flux audio webradio et tu verras que c'est couramment utiliser.

Par exemple sur la page http://www.frameip.com/voip/

Codec standards : H.323 établit des standards pour la compression et la décompression des flux audio et vidéo.

Autrement, Ethernet n'est pas fiable (c'est pas prévu pour, même si cela reste "relativement" fiable)
Par exemple sur la page  http://www.frameip.com/entete-ethernet/

L'Ethernet est basé sur un principe de dialogue sans connexion et donc sans fiabilité. Les trames sont envoyées par l'adaptateur sans aucune procédure de type « handshake » avec l'adaptateur destinataire. Le service sans connexion d'Ethernet est également non-fiable, ce qui signifie qu'aucun acquittement, positif ou négatif, n'est émis lorsqu'une trame passe le contrôle CRC avec succès ou lorsque celle-ci échoue. Cette absence de fiabilité constitue sans doute la clé de la simplicité et des coûts modérés des systèmes Ethernet.

C'est au couche supérieur de gérer la fiabilité. Par exemple TCP.
Et il y a pas vraiment d'horloge Ethernet.

[AJMARS]

Si si... l'horloge parlante....

...