Je crois que les différences entendues sont parfois attribuées à une mauvaise cause
> Diretta … C'est une différence qui s'entend très distinctement il paraît
> Diretta mais beaucoup de témoignages décrivent une amélioration du rendu.
Avec Diretta on utilise un logiciel propriétaire sur le streamer dédié au protocole.
Il se peut que ce logiciel soit très sobre en CPU et réduise ainsi la génération de pollution par le processeur en le sollicitant très peu.
C’est un des avantages de son équivalent dans l’écosystème LMS qui est Squeezelite .
Squeezelite est écrit en C, il est très petit et très peu consommateur.
Des gens entendent des différences entre un fichier flac et un wave alors qu’ils contiennent la même info PCM.
Mais le flac nécessite d’être décompressé au niveau du streamer, processus qui consomme de la CPU, donc pollution près des horloges et du DAC etc…
>Comme le dit Jacques, ce ne sont pas que des zeros et des uns.
Un câble numérique en cuivre peut transporter de la pollution qui n’affectera pas le décodage numérique mais qui peut de proche en proche parvenir à une section « analogique » jamais assez isolée qu’il peut perturber.
>les réseaux informatiques ne sont pas fiables
Ils sont totalement fiables en termes d’information transportées. Cependant le délai et sa variation ne font pas parti du cahier des charges.
Mais cela n’a pas d’importance dans notre cas.
Quelle importance qu’un fichier musical parvienne avec des à-coups temporels au streamer si ce dernier ne commence à jouer que lorsqu’il a le fichier dans sa totalité. C’est équivalent à avoir le fichier sur le SSD du streamer.
> il me semble que des protocoles de type UDP (assez fréquemment utilisés pour l’audio justement) ne vérifient pas ...
Le protocole UDP n’inclus pas d’algo de réémission en cas d’erreur.
Quand un paquet arrive en erreur via UDP il est rejeté par le receveur (grâce au crc) et ce dernier ne demande pas la réémission contrairement à TCP.
L’application qui utilise UDP pourrait demander la réémission mais le plus souvent on utilise UDP quand réémettre ne sert à rien comme en téléphonie puisqu’on est en temps réel.
Alors pourquoi ne pas toujours utiliser TCP ?
Parce qu’UDP a moins d’overhead et qu’il est donc «plus rapide » Aujourd’hui cela n’a plus beaucoup d’importance mais les choix ont été fait dans le passé.
En streaming on utilise TCP.
Mais il n’y a jamais nécessité de réémission.
J’administre un réseau de plus de 800 000 ports Ethernet sur toute l’europe.
Ces ports ont des compteurs d’erreurs. Nous supervisons les compteurs d’erreur avec un logiciel de supervision (NNMI) qui remonte alors une alerte. Il est transmis des milliards de milliards de paquets IP.
Il n’y a jamais d’erreur, sauf quand le câble est abimé ou plié fortement par la porte d’une baie technique ou que quelqu’un débranche puis rebranche un câble. Cela donne alors un pic d’erreur qui disparait après qq secondes.
De toutes ma carrière, le seul protocole qui constamment corrigeait des erreurs ou demandait des retransmissions c’était celui des modems.
> Diretta … C'est une différence qui s'entend très distinctement il paraît
> Diretta mais beaucoup de témoignages décrivent une amélioration du rendu.
Avec Diretta on utilise un logiciel propriétaire sur le streamer dédié au protocole.
Il se peut que ce logiciel soit très sobre en CPU et réduise ainsi la génération de pollution par le processeur en le sollicitant très peu.
C’est un des avantages de son équivalent dans l’écosystème LMS qui est Squeezelite .
Squeezelite est écrit en C, il est très petit et très peu consommateur.
Des gens entendent des différences entre un fichier flac et un wave alors qu’ils contiennent la même info PCM.
Mais le flac nécessite d’être décompressé au niveau du streamer, processus qui consomme de la CPU, donc pollution près des horloges et du DAC etc…
>Comme le dit Jacques, ce ne sont pas que des zeros et des uns.
Un câble numérique en cuivre peut transporter de la pollution qui n’affectera pas le décodage numérique mais qui peut de proche en proche parvenir à une section « analogique » jamais assez isolée qu’il peut perturber.
>les réseaux informatiques ne sont pas fiables
Ils sont totalement fiables en termes d’information transportées. Cependant le délai et sa variation ne font pas parti du cahier des charges.
Mais cela n’a pas d’importance dans notre cas.
Quelle importance qu’un fichier musical parvienne avec des à-coups temporels au streamer si ce dernier ne commence à jouer que lorsqu’il a le fichier dans sa totalité. C’est équivalent à avoir le fichier sur le SSD du streamer.
> il me semble que des protocoles de type UDP (assez fréquemment utilisés pour l’audio justement) ne vérifient pas ...
Le protocole UDP n’inclus pas d’algo de réémission en cas d’erreur.
Quand un paquet arrive en erreur via UDP il est rejeté par le receveur (grâce au crc) et ce dernier ne demande pas la réémission contrairement à TCP.
L’application qui utilise UDP pourrait demander la réémission mais le plus souvent on utilise UDP quand réémettre ne sert à rien comme en téléphonie puisqu’on est en temps réel.
Alors pourquoi ne pas toujours utiliser TCP ?
Parce qu’UDP a moins d’overhead et qu’il est donc «plus rapide » Aujourd’hui cela n’a plus beaucoup d’importance mais les choix ont été fait dans le passé.
En streaming on utilise TCP.
Mais il n’y a jamais nécessité de réémission.
J’administre un réseau de plus de 800 000 ports Ethernet sur toute l’europe.
Ces ports ont des compteurs d’erreurs. Nous supervisons les compteurs d’erreur avec un logiciel de supervision (NNMI) qui remonte alors une alerte. Il est transmis des milliards de milliards de paquets IP.
Il n’y a jamais d’erreur, sauf quand le câble est abimé ou plié fortement par la porte d’une baie technique ou que quelqu’un débranche puis rebranche un câble. Cela donne alors un pic d’erreur qui disparait après qq secondes.
De toutes ma carrière, le seul protocole qui constamment corrigeait des erreurs ou demandait des retransmissions c’était celui des modems.
Switch & Transport Matrix -> DAC Eera -> Ampli Canor KT88 -> HP Atlantis Lab = 