Streaming audio : WiFi versus Ethernet

[Lulu_Dovic]

Merci Nico, je comprends. Je pensais que les bornes wifi mesh pouvaient par défaut se connecter à toutes les box.

[bbill]

De quoi alimenter quelques tabloïds
....
- qualité de communication: un mauvais réseau wifi peut poser des soucis de stabilité et débit, il faut investir dans des appareils performants et ce n’est pas le prix d’un cable réseau à brico merdier…
- qualité audio finale:

C’est sur ce dernier point que le débat peut être le plus compliqué. 

comment savoir si on a un mauvais réseau wifi ?
- du coté de l'émetteur (box)
- du côté du récepteur (drive réseau)
et en général, les deux ne viennent pas du même fabricant ni avec le même objectif (communication <> qualité hifi)

d'un autre coté, avec un réseau câblé, on peut agir (switch & co) alors que le Wifi arrive direct de la box
alors, si on a le choix entre les deux... quel est le bon choix ?

ps : le wifi est parfois présenté comme le miracle, un peu comme le "pont optique" qui était affirmé comme la solution ultime... sauf que, notamment, le récepteur doit être de qualité

ps 2 : et ce n'est pas une question de "Ne pas perdre de paquets lors de la transmission des fichiers audio" comme on le lit parfois.. semble-t-il !? 

[Nicoben]

Quand je parlais de mauvais réseau Wifi à l’époque, ça concernait ceux qui ont des coupures, des débits trop faibles. À priori vis à vis de la qualité audio il n’y a pas de différences d’un wifi à un autre, tout dépend de ce qui se passe à la réception côté Streamer Wifi.

En fait c’est tellement simple et insoluble à la fois: le meilleur entre réseau filaire ou filaire optimisé ou wifi c’est le moins mauvais des trois à l’essai sur UN Streamer considéré

[AudioPhil____.]

Toutafé !
On avait déjà échangé sur le sujet et dans mon cas, après quelques errances et pas mal de sous dépensés dans une solution filaire avec switch, câbles rj, alim, CS ... j'étais revenu au wifi bien foutu de mon Aries G1 Auralic sans frustration, gratos, et bcp de place gagnée en plus.

Puis depuis une semaine je me suis réessayé à la liaison filaire avec le RJ45 Synapse de Jagason ( prototype bientôt sur son site) qui me réconcilie avec la liaison filaire en liaison directe à la box.
ça promet donc si je me relance dans l'optimisation de ce côté !
Mais flemme et en l'état je suis déjà comblé :-)

[bbill]

En fait c’est tellement simple et insoluble à la fois: le meilleur entre réseau filaire ou filaire optimisé ou wifi c’est le moins mauvais des trois à l’essai sur UN Streamer considéré

@Nicoben : réponse claire, chacun doit tester...
@AudioPhil : et tu en donnes 2 bons exemples
mais les tests et comparaisons sont rarement mentionnés sur le forum, on ne voit pas de tendances (et Auralic est une des bonnes exceptions bien connue)

[ThL]

Nagra, bien connu pour la qualité de ses produits, vient de lancer son 1er streamer. Seule une connection filiaire est possible. Linn a abandonné le CD en 2009 au profit du streaming, ici aussi la connection est filiaire.

Je pense que si le wifi était supérieur, ces deux marques l’aurait adopté, non?

Personnellement, le Rj45 sort de mon routeur et se connecte à un switch convertisseur RJ45/optique connecté au 220v, de ce switch sort un câble optique qui se connecte à un second convertisseur Rj45/optique, alimenté par une batterie (et non pas par le secteur 220v). Le second convertisseur est relié au streamer par un RJ45

[hug!]

On ne parle pas assez des box, ou l’on est vraiment à la source pour ce qui du streaming.j’ai récemment changer de boxe, de SFR à Free box révolution. Je crois que c’est la seule chez free que l’on peut tweaker.
Elle est ancienne mais toujours très bonne et nettement au dessus de la SFR que j’avais  

[joseph06]

Un sujet intéressant, je m’abonne.

[KIKIWILLYBEE]

Svp  ,
Revenant , sur mon precedent avis vs.  L’excellente économique de l’introduction d’une tentative de ´bonnes pratiques’ pour une infrastructure 8o2.3 Audio SQ. , et sans revenir sur la définition du NETWORK JITTER. , je vais vous présenter ci dessous un moyen de trouver des métriques comparatives et objectives ´ de test et comparaison pour nous faire comprendre , et objectivement se. permettre de débattre et développer sur le potentiel d’une  infrastructure de référence vs. -> TL‑WR902AC  ( ou autre XX.)
Soit donc à l’aide. d’un soft de mesure reseau standard, comparer numériquement deux infrastructures .

Et donc svp.,
Objectifs : capturer et comparer le même flux RTP ou audio réseau dans deux topologies et comparer le jitter calculé par Wireshark selon la formule RFC 3550.(formule standard)…


I.- Montages à comparer

• Topologie A (référence) : serveur/streamer → switch/routeur principal stable (gigabit) → endpoint audio. (STREAMER.).

Vs.

• Topologie B (avec pocket‑router) : serveur/streamer → TL‑WR902AC. Ou XX.  (en routeur ou point d’accès Wi‑Fi) → endpoint audio.

Il.- Capture Wireshark
• Lancer la capture sur l’interface du endpoint ou sur un port mirroring du switch, dans chaque topologie, avec le même fichier/flux joué en boucle.

• Filtrer le flux (par ex. `rtp` ou filtres IP/port spécifiques au streamer). Wireshark sait identifier les flux RTP et leur appliquer ses stats dédiées.

III.- Analyse du jitter dans Wireshark
• Menu « Telephony → RTP → RTP Streams », sélectionner le flux audio, clic « Analyze » : nous obtientiendront svp.  pour chaque stream le jitter moyen et max.  , pour un graphe de jitter en fonction du temps, et les pertes/retards de paquets.

• Dans la topologie A, matons  typiquement un jitter moyen faible !.  et un graphe relativement plat (variations lentes et modestes -> NETWORK JITTER ., stabilité de la variation de la latence
• Dans la topologie B.XX. avec le TL‑WR902AC. Alias XX. ; constat des pointes de jitter plus élevées, davantage de fluctuations et parfois des pertes/retards (marqués dans la fenêtre RTP comme « lost » ou « late »).

IV.- Graphiques complémentaires
• Toujours dans l’analyse RTP, tu peux affichons le « Jitter Graph » qui montre clairement les oscillations et pics de jitter , variations de la latence encore : c’est ce graphe qui sera l’illustration comparative et en résumé ( de facto.  je n’ai pas de routeur de poche pour réaliser les métriques comparatives  -> (courbe bleue « routeur ‘ principal », courbe rouge « TL‑WR902AC. ou XX.  »)

Que faut il en conclure svp. ?, avez vous des avis ?, et est-ce important ou nécessaire de s’orienter sur ces questions ?

Vous remerciant,
Vous souhaitant un bon week-end.,
Cordialement.,
W. ;-).


Publication du 26 Mars

[Lapinou]

Salut Willy,

tu te rappelles il y a quelques semaines, j'ai posté dans un fil un lien vers un livre blanc de chez DCS sur l'importance du timing en audio, et tu avais écrit que tu comptais lire ce document.

Comme il semble que tu ne l'aies toujours pas lu, je cite ici un extrait de ce document :

Asynchronous Sources

USB & Network Audio sent over an asynchronous format (such as streaming to a smartphone via Spotify, playing content from a NAS via Roon, or playing music from a computer via USB) is, to an extent, the exception to the rules stated in the previous posts, in so much as jitter is not a factor for the audio data, at least until it reaches the endpoint and is converted back to the relevant format (such as PCM or DSD).

With network audio, the interface that is used to send audio data over a network is called TCP (Transfer Communication Protocol). The data which is to be transmitted from one place to another – in this case a piece of music – is split up into multiple packets. These packets contain not only the data itself (the “payload”), but tags on where it has come from, where it is going, how many packets it is part of and how these packets should be reassembled to get the original data back unchanged.

Take, for example, a track from Qobuz being streamed to a dCS Bartok DAC. If a packet of data is lost or compromised, according to the TCP interface, the Bartok can simply request that packet again. When all the correct packets have been received properly by the Bartok, they are unpacked back to the correct data format (PCM, for example) and buffered before being fed to the DAC.

This stage, the unpacking and buffering, effectively removes any timing link between the TCP packets and the resultant audio signal. (Read that sentence again, as it’s very important.)

Ce qui se traduit par :

Sources Asynchrones

L'audio réseau et USB envoyée sur un mode asynchrone (tel que le streaming vers un smartphone via Spotify, la lecture de contenu à partir d'un NAS via Roon, ou la lecture de musique à partir d'un ordinateur via USB) est, dans une certaine mesure, l'exception aux règles énoncées dans les messages précédents, dans la mesure où la gigue n'est pas un facteur pour les données audio, du moins jusqu'à ce qu'elle atteigne le point de terminaison et soit convertie au format pertinent (tel que PCM ou DSD).

Avec l'audio réseau, l'interface utilisée pour envoyer des données audio sur un réseau est appelée TCP (Transfer Communication Protocol). Les données qui doivent être transmises d’un endroit à l’autre – dans ce cas un morceau de musique – sont divisées en plusieurs paquets. Ces paquets contiennent non seulement les données elle-même (la «charge utile»), mais des balises indiquant d'où il vient, où il va, de combien de paquets il fait partie et comment ces paquets doivent être réassemblés pour obtenir les données d'origine inchangées.

Prenez, par exemple, une piste de Qobuz en cours de diffusion à un DAC dCS Bartok. Si un paquet de données est perdu ou compromis, selon l'interface TCP, le Bartok peut simplement demander à nouveau ce paquet. Lorsque tous les paquets corrects ont été reçus correctement par le Bartok, ils sont déballés au format de données correct (PCM, par exemple) et tamponnés avant d'être envoyés au DAC.

Cette étape, le déballage et la mise en mémoire tampon, supprime efficacement tout lien de synchronisation entre les paquets TCP et le signal audio résultant. (Relisez cette phrase, car elle est très importante.)

Pour ceux qui ne connaîtraient pas DCS, ils ont inventé le tout premier ADC 24 bit au monde en 1989, et n'ont pas cessé depuis de produire des équipements de référence dans le domaine de l'audio numérique.

Personnellement, en toute humilité, je veux bien les croire.

Alors : comment expliquer les différences de qualité sonores perçues par certains en fonction de leur infrastructure réseau ? La seule réponse qui me vienne est "autrement".

[Edit : ajout du lien vers le site Web de DCS]