Le Forum Indépendant de la Hifi et des Audiophiles

UDP?????
C'est un gars qui développait des jeux en ligne ou du broadcast video qui a conçu RAAT?

Si ça marche...

Pas d'accusés de réception, pas de re-émission de paquets perdus ou corrompus, pas de vérification des données. 

Résultats non systématiquement reproductibles. 

Indispensable pour ne pas surcharger un serveur de jeu ou de broadcast video, au prix de freeze et de pertes de certaines images, choix étonnant, de mon point de vue, pour une application "HIFI".

https://community.roonlabs.com/t/roon-1-...live/26719

Ils utilisent le protocole TCP.

(07-26-2017, 08:09 PM)ThierryNK a écrit : [ -> ]Pas d'accusés de réception, pas de re-émission de paquets perdus ou corrompus, pas de vérification des données. 

Résultats non systématiquement reproductibles. 

Indispensable pour ne pas surcharger un serveur de jeu ou de broadcast video, au prix de freeze et de pertes de certaines images, choix étonnant, de mon point de vue, pour une application "HIFI".

Pourquoi faire ça sert à rien en hifi non ?  ...désolé je sort ! elle était facile

---

(07-26-2017, 07:30 PM)Olivier a écrit : [ -> ]

(07-26-2017, 06:52 PM)LittleScarabee a écrit : [ -> ]Sais-tu pourquoi c'est le mot "Bridge" qui a été utilisé par Roon pour indiquer son "client", car le mot "Player | Streamer" paraît plus approprié mais il y a surement une explication ...

Car au niveau des boîte type PS Audio on parle de "Roon Ready" pour les "network player" jusque là ça se comprend facilement...

Je pense personnellement, que le terme bridge vient du fait que le serveur pousse le flux vers le client. Un streamer va récupérer une adresse ou URL et va chercher sur le support de stockage le fichier à lire... c'est du moins ma vision simpliste...

Oui le mot streamer est plus adéquate pour le serveur en lui même qui stream / envoi le flux audio vers le client...perso ça me perturbe le mot bridge pour un client audio...après si c'est pour dire "pont" entre le serveur et le DAC, why not...mais bon y'a mieux comme nom à donner je pense

---

(07-26-2017, 07:30 PM)volpone75 a écrit : [ -> ]

(07-26-2017, 06:52 PM)LittleScarabee a écrit : [ -> ]Sais-tu pourquoi c'est le mot "Bridge" qui a été utilisé par Roon pour indiquer son "client", car le mot "Player | Streamer" paraît plus approprié mais il y a surement une explication ...

Car au niveau des boîte type PS Audio on parle de "Roon Ready" pour les "network player" jusque là ça se comprend facilement...

Moi je trouve que c'est assez parlant comme nom. 

Le programme RoonBridge gère un flux ethernet numerique UDP en entrèe pour sortir du PCM ou du DSD. Fonctionnellement c'est une simple passerelle. Au départ en 2015 ROON dénommait RoonBridge RoonSpeakers mais personne n'y comprenait rien.

PSaudio appelle aussi Bridge sa carte réseau (et le programme qui la pilote) mais c'est son DAC globalement qui est labelisé "RoonReady" quand on lui adjoint le fameux Bridge.

Dans ce cas autant appeler un chat un chat et utiliser le mot "gateway" car finalement on peut aussi considérer que c'est une passerelle...PS Audio n'aide en rien à la bonne compréhension..car le mot bridge c'est un pont entre deux éléments ...en effet on peut dire qu'il fait aussi de pont entre un DAC et une source audio, mais c'est tiré par les cheveux...pas logique tout ça pour moi, désolé

Je ne cherche pas de créer un "sujet épidermique" je me suis clairement poser la question et essayé de comprendre la logique de Roon derrière ça

Merci.

---

(07-26-2017, 08:12 PM)paulw a écrit : [ -> ]https://community.roonlabs.com/t/roon-1-...live/26719

Ils utilisent le protocole TCP.

Merci, cela aurait étonnant de s'appuyer sur un protocole UDP et se priver des avantages du TCP.

(07-26-2017, 08:09 PM)ThierryNK a écrit : [ -> ]Pas d'accusés de réception, pas de re-émission de paquets perdus ou corrompus, pas de vérification des données. 

Résultats non systématiquement reproductibles. 

Indispensable pour ne pas surcharger un serveur de jeu ou de broadcast video, au prix de freeze et de pertes de certaines images, choix étonnant, de mon point de vue, pour une application "HIFI".

Hello,
RAAT transmettait à l'origine l'audio exclusivement en UDP, comme AIRPLAY d'ailleurs.

Depuis la dernière mise à jour majeure (B234 en juin 2017), c'est du TCP. Cela fonctionnait parfaitement en UDP et cela continue a fonctionner parfaitement en TCP . J'utilise Roon en réseau assez intensivement depuis mai 2015 et n'ai jamais eu aucun problème de transport.

Pour les "techos" à l'estomac solide qui ont assez de temps et d'appétit pour approfondir les évolutions du protocole RAAT un extrait de la "release note" qui explicite le pourquoi du comment (on peut aussi s'en passer et zapper): https://community.roonlabs.com/t/roon-1-...live/26719

Citation :Most audio streaming protocols are designed, implemented in hardware, and then set in stone. This happens because updating firmware in hardware devices is difficult, and when that hardware is made by dozens of different manufacturers it’s nearly impossible. That’s why most AirPlay users never install a firmware update--the device is speaking the same AirPlay protocol it did on day one.
In an ecosystem like that, evolving is difficult--too many changes and you end up with a range of devices each with slightly different behavior. This is a nightmare for QA and support, so device implementations for protocols like UPnP AV and AirPlay are often set in stone.
When we set out to design RAAT, we hoped for a brighter future -- a future that can evolve with our budding hardware ecosystem. Trying to push firmware updates to Roon users via our 60+ hardware partners wasn’t realistic, so we designed RAAT to work differently: Instead of baking the audio streaming protocol into the device firmware, the firmware contains the absolute minimum needed for us to "boot" a second piece of code delivered to the device the time when the Roon Core makes its connection to the device. This second piece code--delivered "just in time"--defines the streaming protocol that Roon uses to speak with RAAT devices.
Today's release of the core includes a re-design of RAAT's audio streaming protocol that uses TCP instead of UDP to transmit the audio stream.
In day-to-day life, most of the protocols you use are TCP-based--browsing the web, viewing Netflix or Youtube. Streaming audio using TIDAL, Spotify, OpenHome, UPnP, MPD, or SMB. The two most popular UDP streaming systems that most people have contact with are AirPlay and Skype.
We have decades of experience building audio streaming protocols around UDP, and it has generally been our first choice, but we also know that both TCP and UDP, when implemented properly, are suitable for high-bandwidth, high-quality media streaming, so it was worth undertaking an exploration of "the other side" to see if there was actually a reason to consider switching.
After a series of experiments and prototypes, and a detailed exploration of both approaches, we found that we were able to extract more performance and reliability from TCP, so we took it to the next phase and started experimenting with TCP in our alpha environment a couple of months ago.
We found that using TCP reduces CPU load on the audio device and in the core--primarily by reducing the context switching overhead associated with “waking up” for each packet. Using TCP also allows us to offload work associated with re-assembling the packetized audio stream from RAAT to the operating system kernel on the audio device, where it can be implemented more efficiently and simply.
We also found that TCP is a lot "friendlier" to poor networks and routers. Not all router manufacturers perform extensive QA with high-resolution UDP audio streams, but they all test to make sure Netflix and Youtube (both TCP-based) work. TCP is also less likely to create trouble with exotic network setups--managed switches, jumbo frames, etc. If you have experienced trouble with these, it's definitely worth taking another shot to see if the new protocol is easier on your network.
This change rolls out as part of the update to your Roon Core--which will use the new protocol when speaking to all RAAT-based zones. Aside from updating the core, no firmware or software updates are required on any of your devices.

Bonjour,

Question sur le setup de Roon avec mon Devialet. J'utilise 2 Mac mini, un lecteur avec Roonserver, un second avec Roon complet en mode télécommande.
Dans le setup audio, je vois décrit dans l'ordre :
- en local, Air sur le Mac télécommande
- sur le Mac Roonserver, Air également.
- sur le réseau, mon Devialet.

Je définis donc 2 zones, la première avec Air sur Roonserver qui me permet notamment de paramétrer le direct Mode, etc, et une seconde zone pour le Devialet avec moins de réglages possibles.
Ce fait de devoir décrire 2 zones est-il normal ? Seule la sélection de ma zone Devialet me permet d'avoir du son.

Merci de vos éclairages.

Bonjour Demetrios,
Je pense que tu as le driver Air Devialet (celui de de Devialet) qui est actif sur les 2 Mac mini et Roon voit donc 3 Devialet Air.
Celui sur le Mac mini télécommande, celui sur le Mac mini serveur, et celui en direct via Roon (à partir du serveur très probablement).
C'est ce dernier qu'il faut utiliser, il est facile à reconnaitre car le logo montre un Devialet Expert, les autres marchent aussi mais à condition qu'ils soient actifs.

Je te conseille (si tu ne l'as pas déjà fait) de les désactiver purement et simplement et de ne pas lancer l'application Devialet Air qui, de toutes façons, ne sert plus à rien, et mange surement un peu de ressources sur les Mac mini.

(07-27-2017, 09:47 AM)Demetrios a écrit : [ -> ]Bonjour,

Question sur le setup de Roon avec mon Devialet. J'utilise 2 Mac mini, un lecteur avec Roonserver, un second avec Roon complet en mode télécommande.
Dans le setup audio, je vois décrit dans l'ordre :
- en local, Air sur le Mac télécommande
- sur le Mac Roonserver, Air également.
- sur le réseau, mon Devialet.

Je définis donc 2 zones, la première avec Air sur Roonserver qui me permet notamment de paramétrer le direct Mode, etc, et une seconde zone pour le Devialet avec moins de réglages possibles.
Ce fait de devoir décrire 2 zones est-il normal ? Seule la sélection de ma zone Devialet me permet d'avoir du son.

Merci de vos éclairages.

Bonjour Demetrios,

[img][/img]

De mon point de vue, tu devrais:

• quitter Devialet AIR lorsque tu utilises Roon/AIR; tu n'as ainsi qu'une seule zone à définir
  
• attaquer ton Devialet idéalement depuis le MacMini sur lequel tu as une alimentation linéaire (RoonServer), et utiliser le second en serveur de fichiers et en télécommande
  

PS: Ah, pda0 m'a grillé une fois de plus

Les explications de Roon sur UDP/TCP sont de l'enfumage pour les clients non technologues et une grosse rigolade pour les autres.

Amitiés