streamers, mesures ou écoutes?

[tades]

Merci Kiki d'avoir produit cette synthèse.
Par contre je ne parviens pas à faire le joint avec le fait que la transmission soit synchrone ou asynchrone (eg j'ai cru comprendre que RJ45 = asynchrone serait de meilleure qualité qu'une liaison usb qui serait partiellement synchrone (là vous voyez comme je patauge ;-)

Meilleurs Voeux à vous tous qui éclairez notre lanterne !

[bbill]

c'est bien d'avoir une synthèse globale de la théorie mais il est aussi important de définir les vrais problèmes..

[KIKIWILLYBEE]

Bonsoir ,

Yep, svp :
Ni synchrone, ni asynchrone ,
C’est un FLUX ISOCHRONE , à récurrence temporelle stricte (dans le cas idéal ), altèré par la Guigue (délais, latence ,over all paquet latency , paquet loss …)
Ou a debit constant ou bande passante garantie …

Un buffer , ou tampon peut rendre le flux +/_ asynchrone , mais introduira du délai : constituant du jittter …
Mais effectivement c’est de la théorie …

Yess , BBILL , l’académisme , ne supplante en rien l’observation du réel ..!! ;-) …

…
….

Bien cordialement,

[rastabill]

Merci KiKi et meilleurs vœux à toi et tes proches. 

Je pense avoir bien saisi les différent points détérioration de nos fichiers audio quand il circule dans nos chère Rj45.
Certain lecteur réseau on des paramètres réglables qui vienne de alsa de Linux. 

Sous Linux il existe beaucoup de paramètres audio qui reste réglable. 
Nrpack (taille de paquet qui circule en réseau) 
Buffer time (qui définit la taille du paquet qui part) 
Period count (Le temps entre chaque départ) 
Steam buffer
Output buffer

Le réglage de ces paramètres et une bonne gestion des tempons devrait minimiser les problèmes de latence ?

Pour ce qui est de l'intégrité des paquets qui circule dans le réseau c'est plus vers les switch ou router qu'il faut regarder ?

[bbill]

(01-03-2022, 09:42 PM)KIKIWILLYBEE a écrit : Yess ,  BBILL , l’académisme , ne supplante en rien l’observation du réel  ..!! ;-) …

justement à propos de réel, je reviens avec ma question de la page précédente à laquelle tu n'as pas répondu :

(01-03-2022, 07:06 PM)KIKIWILLYBEE a écrit : Celà altère l’intégrité des données et paquets tcp et adresses ip, et corrompt donc l’intégrité des fichiers ou flux transmis 

crois-tu vraiment que c'est le problème pour la partie drive réseau ??? 

[Pascal64]

condor64 a écrit : tant qu'on y retrouve ses 0 et ses 1 c'est tout bon,

Oui mais non 
Willybee a répondu plus haut.

Un signal carré est bien plus complexe qu'on ne pourrait le croire.
Ex : ça déclenche à combien ? pour passer de 0 à 1 , la vitesse de montée , le palier plus ou moins rectiligne ... c'est ce qu'on appelle la guigue ou jitter. 
pour arranger le tout, ça doit calculer à un rythme effréné de 44000 fois par seconde.

Alors que faire pour que les paquets (combien d'octets pour une note ?) soient bien rangés ?
Des horloges de précision partout, sur le lecteur, dans le DAC, sur le réseau. Ok
Rajoute le bordel rejeté par les alims , la pollution des processeurs etc qui va perturber nos précieuses horloges 
Bref, un joyeux boxon 

[François H.]

(01-03-2022, 06:06 PM)bbill a écrit :

(01-03-2022, 05:54 PM)condor64 a écrit : Ce qui serait intéressant c'est des mesures non pas en sortie de streamer - tant qu'on y retrouve ses 0 et ses 1 c'est tout bon, il s'agit de data 

c'est ton hypothèse ou ta certitude ?
comment expliques-tu alors des différences notables entre drives réseau ?

En tout cas, pour l'avoir constaté à de multiples reprises, c'est indéniable !
Avec le même convertisseur et les mêmes câbles, les différences entre streamers sont é-vi-den-tes !

[ds21]

Meilleurs Vœux à tous.

Non seulement le streamer influence le rendu sonore, mais aussi le logiciel du serveur entre en ligne de compte:

Une remarque concernant le streaming avec Qobuz.

Selon que j’utilise Qobuz avec roon ou bien avec LMS, le comportement en streaming est différent.
Dans les 2 cas la reception se fait en tcp (et pas udp) avec en théorie une correction en cas d’erreurs de transmission de paquet.

Seulement, depuis quelques temps, j’ai sur mon système, des coupures Qobuz avec LMS parce que la réception des données par le nuc se fait au même débit que celui auquel le morceau est envoyé au lecteur et donc la marge de rattrapage est très faible (du moins, je l’interprète comme ça)

Alors qu’avec roon, le morceau streamé en provenance de Qobuz est reçu au débit maxi autorisé par ma box (10 Mbits/s chez moi) et copié sur le disque dur, ce qui autorise, me semble-t-il, une meilleure gestion des rattrapages en cas de petites erreurs de transmission. Bien sûr, il n’y a pas de latence au démarrage de la lecture des pistes avec Qobuz sous roon (la lecture commence en même temps que le début de la transmission de la piste par Qobuz) et je n’ai pas de coupure de flux avec roon.

Je peux observer tout ça grâce au gestionnaire de tâches et au moniteur de ressources sous win10 et grâce également au fait que chacun des process roon, lms serveur et squeeze2upnp tourne sur son cœurs spécifique.

Tout ça pour dire que, peut-être, la méthode de gestion du streaming a des conséquences sur le résultat à l’écoute.

Cdlt

[condor64]

Bien lu, le tout étant de trouver le bon qui ne soit pas à des tarifs astronomiques...
je n'ai que l'expérience du Node2 et du Lumin U1 mini (pas si différent, sauf sur la largeur de la scène sonore - ou alors c mon cerveau - sans doute à cause du matériel en aval pas suffisamment concluant)

[François H.]

(01-04-2022, 09:35 AM)condor64 a écrit : … je n'ai que l'expérience du Node2 et du Lumin U1 mini (pas si différent, sauf sur la largeur de la scène sonore - ou alors c mon cerveau - sans doute à cause du matériel en aval pas suffisamment concluant)

C'est marrant, ce sont deux des streamers que j'ai pu essayer chez moi.

Pour moi, les différences étaient flagrantes en définition, ouverture, propreté du signal (et pas uniquement largeur de scène !) à l'avantage du Lumin bien sûr !