01-04-2022, 09:34 AM
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
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
Qobuz sublime -> wifi -> Tenda wifi mesh[LPS] -> rj45 yauhody CAT8 -> mini PC AMD Ryzen7 7730U[LPS]+SSD 4To/boitier inateck[LPS] - roon+HQPembedded (PCM>>DSD256) / Gentooplayer -> rj45 yauhody CAT8 -> IFI LAN ipurifier -> DST-00/Diretta[alim LHY accu] -> HDMI I2S cumulus-concentus -> Holo audio cyan2[IFI nova] -> XLR Grimm SQM -> Topping Pre90[IFI supanova] -> XLR Xangsane SP-9001-AG -> Benchmark AHB2[IFI nova] -> câble HP mulidine -> Mulidine Cadence