Wifi/ethernet, instabilités, fiabilité des données

[mélaudiophile]

(10-22-2023, 09:58 PM)ThierryNK a écrit :

(10-22-2023, 09:28 PM)tipunch a écrit : Ok alors évite de ramener ta fraise quand tu n’as ni mesuré et ni testé!

Le smiley ne change rien. 

Voilà une justification du fait que je ne mets plus de smileys.... je n'aime pas ça - faiblesse d'écriture, hypocrisie, ...

[zaurux]

@ThierryNK : peux-tu préciser l'impact de la latence dans le cadre d'une utilisation en streaming audio comme je le pratique via Qobuz ou NAS.
Effectivement, il y a de la latence mais celle-ci est très gênante quand tu traites des entrées/sorties (jeux vidéos, ordre d'avant à la clôture du marché... ou achat sur Ebay).

Dans le cas que je pratique, la latence n'a d'impact que dans les commandes de lecture Roon mais, sauf erreur, le flux arrive, est stocké en buffer. Là ce sont les buffers qui jouent le jeu. EX. "stop" sur l'ordi de commande en wifi et arrêt plus d'une seconde après.. le temps que le buffer se vide.
Une fois sur le serveur, il est traité par HQplayer. La qualité du fonctionnement du serveur est tributaire de la latence logicielle (qualité de l'intégration des drivers et de l'interface entrées/sorties des commandes logicielles.. essentiellement le driver ndis.sys). Ensuite tout est envoyé au streamer en UDP.
Par contre, je valide totalement cette solution Mesh mise en place depuis presque 3 ans qui par sécurité est sur alimentation linéaire avec toutefois un filtre entre sa sortie rj45 et l'entrée du serveur audio (JCAT Femto).

[Vincent De Paris]

Les réseaux wifi/ethernet utilisent des mécanismes de détection d'erreurs. Cela signifie que si des erreurs sont détectées les données sont retransmises.
Lorsque des données sont transmises un code CRC est calculé. Le code CRC est calculé par le récepteur également. Si les codes ne correspondent pas le paquet de données est rejeté. La retransmission du paquet de données est organisé par le protocole de transmission.
Dans le cas de problèmes de transmission, les réseaux peuvent réduire la vitesse de transmission (appelée "rate adaptation") pour améliorer la stabilité de la connexion.
Ces mécanismes permettent aux données de voyager sur des dizaines de milliers de kilomètres en passant par des centaines de switches sans pertes.

[ThierryNK]

Salut 

@zaurux
Je n’ai aucune latence ni à l’arrêt ni au changement de pistes Qobuz. 
Parfois qq chose comme une demi seconde au démarrage d’un album Qobuz. 
A ma connaissance, ce n’est plus UDP qu’utilise Roon mais TCP.

Amicalement

[zaurux]

(10-25-2023, 11:38 AM)ThierryNK a écrit : Salut 

@zaurux
Je n’ai aucune latence ni à l’arrêt ni au changement de pistes Qobuz. 
Parfois qq chose comme une demi seconde au démarrage d’un album Qobuz. 
A ma connaissance, ce n’est plus UDP qu’utilise Roon mais TCP.

Amicalement

Je parlais d'HQPlayer > streamer qui transmet en UDP sous IPV6
Le schéma est web > wifi/mesh > Roon > HQPlayer > streamer.
Et la latence, effectivement n'est pas dans la commande. Je voulais rappeler la sécurisation des buffers. Si je débranche matériellement le réseau, j'ai 2 secondes de musique (mini) en mémoire.

[ThierryNK]

Ok, mais je n’utilise pas HQP    et lors d’un essai de modulateur delta sigma avec HQP, les latences étaient effectivement très importantes. Mais c’est HQP, pas le wifi. 

Oui, effectivement pour les buffers. 

Amicalement