Steph-Hifi a écrit:..... encore faudrait t'il etre certain que UDP soit utilisé (je crois que ce n'est pas le cas avec roon, ni upnp, ni le DLNA) et au dela de cela ces suppositions sont balayées par les mesures d'amir.
pour ma part je ne crois pas un seul instant a ce que des bit se perdent avec un switch reseau classique connecté a quelques metres de son streamers, je ne connais pas la facon dont upnp (qui n'utilisent pas UPD mais TCP si je m'abuse) voir le DLNA (qui je crois n'utilisent pas udp non plus) s'acquittent des données recues (en TCP il y a acquittement).
mais pour ma part je n'ai jamais eu le moindre tic/clac ou desyncronisation de n'importe quel film en DTSHDMA connecté sur mon switch à 40 euros qui est relié a mon NAS synology alors bon pour du pauvre PCM 44,1 (voir de l'OGG ou du MP3) je ne crois pas un seul instant qu'un bit se perde. je le répète inversons la charge de la preuve
jacko a écrit:AMHA, la vrai question est de savoir comme le steamer, renderer etc. va gérer le flux de données, plus que la problématique des éléments hardware qui composent le réseau.
Encore faut-il que le streamer, renderer, etc ait reçu des données correctes en UDP.
Cdlt.
Si les paquets sont mis en cache et contrôlés où serait le problème ?
ds21hcfr a écrit: Encore faut-il que le streamer, renderer, etc ait reçu des données correctes en UDP.
Cdlt.
Si les paquets sont mis en cache et contrôlés où serait le problème ?
Paquets mis en cache et contrôlés ?
Mais en UDP, si un paquet a une erreur de bits dans la partie utile du message musical transporté et qu’il n’y a pas de checksum d’activé pour contrôle comme ça peut être le cas en IPv4, il n’y a aucun contrôle et je ne vois pas en quoi la mise en cache changerait quoi que ce soit.
jacko a écrit:Chez moi : Jriver Mise en cache de l'intégralité du morceau avant lecture Tout problème quelque soit sa nature résolu
A part le gapless qui va alors dépendre de la taille du fichier et du temps nécessaire pour sa mise en cache. Mais comme le gapless ne m'intéresse pas ...
Le gapless m'étant nécessaire obligatoirement pour l'écoute de musique, je n'ai pas mis en fonction la copie dans le cache. Et aussi parce que le boss de Jriver dit que cela ne joue pas sur la qualité sonore et qu'il a implanté cette fonction parce qu'on la lui demandait.
En tout cas, ça résout éventuellement des problèmes : mais si tu corriges paramétriquement par exemple : il met quoi en mémoire cache ? Le signal corrigé ?
Si il y a une correction elle se fait forcément après le décodage car ça travail en PCM. C'est donc après la mise en cache Vu que j'ai un DDRC22A de toute manière je ne le souci pas de la logique de l'architecture de Jriver sur le point.
jacko a écrit:AMHA, la vrai question est de savoir comme le steamer, renderer etc. va gérer le flux de données, plus que la problématique des éléments hardware qui composent le réseau.
Oui, la façon dont le flux de données va être transformé en PCM... il me semble que plus haut Steph-hifi en a parlé.
Je parle du protocole de transfert et comment les données sont traitées.
Je ne pense pas qu'il y ait 36 méthode pour qu'un FLAC, ALAC, APE etc. soit converti en PCM pour alimenter le DAC. Se sont des formules bien définies.
renecito a écrit:Et alors ? En quoi le switch "audiophile" ne serait pas impacté par la fausse problématique ?
Je ne suis pas un adepte du switch audiophile. Simplement, dans le cadre d’une transmission de flux en protocole UDP qui autorise des paquets contenant des erreurs, je me dis que, peut-être, certaines dispositions technologiques particulières (encore faut-il les trouver, les mettre en œuvre et les tester) pourraient diminuer le taux d’erreurs.
jacko a écrit: Si les paquets sont mis en cache et contrôlés où serait le problème ?
Paquets mis en cache et contrôlés ?
Mais en UDP, si un paquet a une erreur de bits dans la partie utile du message musical transporté et qu’il n’y a pas de checksum d’activé pour contrôle comme ça peut être le cas en IPv4, il n’y a aucun contrôle et je ne vois pas en quoi la mise en cache changerait quoi que ce soit.
Cdlt
Comme indiqué par Steph-hifi, pourquoi veux tu absolument que le protocole soit UDP ?
pour ma part j'utilise uniquement le service de partage de fichier SMB en TCP/IP de mon NAS et volumio (l'OS de mon streamer) bufferise le fichier avant lecture dans une mémoire tampon de 2 megabit... bref complétement insensible aux switchs.
Mais, il y a des logiciels qui ne bufferisent pas les flux ??? Parce que comme tu dis, si il y a buffer, y'a pas de problème, et si problème il y a on l'entend parfaitement (coupure franche).
La bougie de ton intelligence n'éclairera ta vie que le jour où tu arrêteras toi-même de souffler dessus ! On ne peut pas donner à boire à un âne qui n'a pas soifπ
jacko a écrit: Je parle du protocole de transfert et comment les données sont traitées.
Je ne pense pas qu'il y ait 36 méthode pour qu'un FLAC, ALAC, APE etc. soit converti en PCM pour alimenter le DAC. Se sont des formules bien définies.
quel rapport avec les protocoles de transmission et les switchs (audiophiles ou non)
Si tu lisais l'ensemble des échanges tu comprendrai le cheminement qui conduit à ces remarques. Mais à priori ce n'est pas ce qui t'importe ou ce que tu recherches ...