Streamer haut de gamme

[Pascal64]

(07-18-2018, 01:27 AM)KIKIWILLYBEE a écrit : Bonsoir !,

SVP ?, : à ce propos  :

(07-17-2018, 11:30 PM)volpone75 a écrit : "Si pour le jitter je ne vois pas comment le serveur pourrait avoir la moindre influence pour le bruit ..",

Je serait à même de penser que chacun des éléments additionnés à la chaine ajoutera du jitter ?,
les erreurs ne s'additionnent elles pas  ?
(en tous cas au moins leurs dérivées ?)...

+1 
Le jitter est partout et le serveur n'est pas epargné comme par miracle 
le travail en amont du DAC ou du Player est tout aussi indispensable que le reste  

Citation :mais cà ne semble pas correspondre aux  observations ?....

Si, et cela fait belle lurette que certains l'ont compris.
Volpone75 fait juste un peu de resistance 

Citation :svp, en ex les origines du jitter 




ces différents aspects :
https://www.keysight.com/upload/cmc_uplo...nload2.pdf

bien à vous,
cdlt,
w :-)

Merci Willy pour ce doc.
Des l'instant ou les données sont transmises, c'est le bazard, comme l'explique aussi Vincent

(07-18-2018, 08:44 AM)Vincent. a écrit : Ce qui ne change rien au fait que les bits en sortie de la passerelle et vers le DAC soient bien transportés (ou non).

Toutes ces discussions me rappellent celles des débuts de l'uSB asynchrone.
Certes le DAC impose son horloge mais faudrait tout de meme éviter de lui envoyer du Jitter dans les dents.

le travail en amont du DAC est tout aussi indispensable que le reste 
(bis repetita)

[Vincent.]

Difficile d'être clair visiblement. Je ne parle pas du serveur, mais du flux audio qui arrive en entrée du DAC. Et oui il peut y avoir des erreurs, ce qui ne fait pas s'écrouler le monde audio. Le document Agilent (ex Hewlett-Packard) est éclairant (et leurs appareils de mesure font référence dans le domaine depuis des décennies).

[mélaudiophile]

(07-18-2018, 08:44 AM)Vincent. a écrit : Ce qui ne change rien au fait que les bits en sortie de la passerelle et vers le DAC soient bien transportés (ou non).

Que l'on me corrige si je me trompe, mais j'ai du mal avec ce schéma.
Il oublie la correction d'erreur qui va remettre l'original en place grâce aux octets de parité. Il présente les choses comme si le flux de bits était utilisé tel qu'il arrive. Dans ce cas le digital ne marche pas.

jean

[volpone75]

(07-18-2018, 10:00 AM)Vincent. a écrit : Difficile d'être clair visiblement. Je ne parle pas du serveur, mais du flux audio qui arrive en entrée du DAC. Et oui il peut y avoir des erreurs, ce qui ne fait pas s'écrouler le monde audio. Le document Agilent (ex Hewlett-Packard) est éclairant (et leurs appareils de mesure font référence dans le domaine depuis des décennies).

Si tu ne parles pas de l'influence du serveur en terme de jitter la discussion n'a pas lieu d'être car mon propos était de constater qu'il n'avait aucune influence dans ce type d'architecture réseau compte tenu de l'asynchronisme et qu'en conséquence son optimisation en la matière n'avait aucun sens. Pour prendre une image, vu du DAC la passerelle réseau est un fichier (sans bits manquants ou altérés) pas un flux audio.

[Vincent.]

(07-18-2018, 10:13 AM)mélaudiophile a écrit :

(07-18-2018, 08:44 AM)Vincent. a écrit : Ce qui ne change rien au fait que les bits en sortie de la passerelle et vers le DAC soient bien transportés (ou non).

Que l'on me corrige si je me trompe, mais j'ai du mal avec ce schéma.
Il oublie la correction d'erreur qui va remettre l'original en place grâce aux octets de parité. Il présente les choses comme si le flux de bits était utilisé tel qu'il arrive. Dans ce cas le digital ne marche pas.

jean

Tout dépend à quel endroit de la transmission on se situe.
Entre le lecteur réseau et le DAC, c'est un flux PCM qui circule dans un seul sens : est-ce que le PCM intègre un code de correction d'erreur ? (dans mes souvenirs, les CRC sont mis en œuvre dans les protocoles télécom (longue distance au départ, puis LAN) pour en effet pouvoir récupérer de l'info perturbée au cours de la transmission) ?
Ca supposerait aussi que les puces embarquées dans les DAC sachent traiter le CRC. Si vous avez de l'info là-dessus, je suis preneur.

---

(07-18-2018, 10:27 AM)volpone75 a écrit : ...

Si tu ne parles pas de l'influence du serveur en terme de jitter la discussion n'a pas lieu d'être car mon propos était de constater qu'il n'avait aucune influence dans ce type d'architecture réseau compte tenu de l'asynchronisme et qu'en conséquence son optimisation en la matière n'avait aucun sens. Pour prendre une image, vu du DAC la passerelle réseau est un fichier (sans bits manquants ou altérés) pas un flux audio.

J'ai l'impression qu'il y a deux choses différentes : ce qui est en amont de la passerelle réseau (échange de fichiers) et je serais plutôt enclin à ne pas m'en préoccuper. Et ce qui est en aval de la passerelle vers le DAC, un flux PCM unidirectionnel (voir ma question ci-dessus).

[0000]

(07-18-2018, 09:58 AM)Pascal64 a écrit :

(07-18-2018, 01:27 AM)KIKIWILLYBEE a écrit : Bonsoir !,

SVP ?, : à ce propos  :

(07-17-2018, 11:30 PM)volpone75 a écrit : "Si pour le jitter je ne vois pas comment le serveur pourrait avoir la moindre influence pour le bruit ..",

Je serait à même de penser que chacun des éléments additionnés à la chaine ajoutera du jitter ?,
les erreurs ne s'additionnent elles pas  ?
(en tous cas au moins leurs dérivées ?)...

+1

Addition 1 + (-1) = 0


erreur + correction d'erreur = ?

[Pascal64]

= interpretation 

[volpone75]

(07-18-2018, 10:36 AM)Vincent. a écrit : ...
J'ai l'impression qu'il y a deux choses différentes : ce qui est en amont de la passerelle réseau (échange de fichiers) et je serais plutôt enclin à ne pas m'en préoccuper. Et ce qui est en aval de la passerelle vers le DAC, un flux PCM unidirectionnel (voir ma question ci-dessus).

On est d'accord sur le fait qu'il y a deux choses différentes. Dans notre contexte le document HP cité sème la confusion plus qu'il n'éclaire. On est très loin d'être en temps réel en audio bien que le terme de "streaming réseau" puisse le faire penser:

En amont de la passerelle réseau cela peut être assimilé à du transport de fichier (asynchrone). La notion de jitter n'est pas pertinente et sauf catastrophe il n'y a pas d'erreurs de bits. Si ce n'était pas le cas cela se saurait. Ne pas s'en préoccuper me semble raisonnable, c'est exactement ce que je préconisais  

Entre la passerelle et le DAC il y a potentiellement une problématique de jitter pouvant influer sur le signal analogique après conversion. Le consensus est qu'en règle général c'est plutôt bien maitrisé actuellement par les constructeurs qui optimisent DAC et passerelle pour cela (avec des différences de performances en fonction des interfaces). C'est un autre débat marronnier ...

Tout ça pour dire qu'aller mettre des horloges atomiques sur un serveur pour minimiser le jitter n'avait aucun sens. Un PC de base fait le job. CQFD.

[KIKIWILLYBEE]

Bonjour,
comme l'évoque Vincent :
les CRC sont mis en œuvre dans les protocoles télécom"...
et le remarque Jean : peu de chose sans ...
Mais dans nos application audio , aucun protocole de correction !,
qui n'est qu'une couche logicielle au dessus du matériel.

Effectivement le jitter est un des sujets principales des telecom's,
et on observe pour l'exemple trivial et édifiant que la VOip :
(transmission d'un signal audio PCM....)
voix et téléphonie sur réseaux ethernet ne fonctionne pas de façon suffisante
(latence, paquet loss...)
sans certaines précautions : sinon la voix, la  conversation n'est pas intelligible :
en résumé des actifs réseaux de qualité superieure (CISCO , LUCENT, NORTEL, AVAYA etc...('vec des horloges de compet'.)), et du software
déployé sur la couche matérielle sous forme d'une
- Qos (qualité de service) :
dans la gestion du protocole, des trames IP (UDP )
puis pour rendre la conversation intelligible :
- une ouverture de session point à point (SIP),
- dans laquelle s'active un protocole spécifique de gestion du TEMPS
point à point (RTCP) ;
-et en surcouche encore un protocole de transmission audio
spécifique Hxxx. (H323)......

...?

[0000]

(07-18-2018, 11:06 AM)Pascal64 a écrit : = interpretation 

(07-18-2018, 11:13 AM)volpone75 a écrit : Entre la passerelle et le DAC il y a potentiellement une problématique de jitter pouvant influer sur le signal analogique après conversion. Le consensus est qu'en règle général c'est plutôt bien maitrisé actuellement par les constructeurs qui optimisent DAC et passerelle pour cela (avec des différences de performances en fonction des interfaces).

En pratique, la préférence personnelle sur le rendu sonore pourrait aussi être assimilée à une sorte de "jitter audiophile".
Si vous savez des études sur l'influence positive ou négative de faible jitter sur le ressenti à l'écoute, je suis preneur.