Bit-perfect avec UPnP / Moode ou Ropieee

[Nard]

Pour le PCM supérieur à 48kHz, certainement pas !

P. ex.  un flac 24/96 décodé par Bubbleupnp sous Android est envoyé en PCM 24/96 au streamer Openhome émulé par Bubbleupnp server sur le Nas qui l'envoie à son tour au streamer réel non Openhome (sauf si on a demandé que le décodage soit fait par Bubbleupnp server, dans ce cas le smartphone n'est plus qu'un simple contrôleur)

[comas]

(05-22-2020, 11:20 PM)Nard a écrit : Pour le PCM supérieur à 48kHz, certainement pas !

P. ex.  un flac 24/96 décodé par Bubbleupnp sous Android est envoyé en PCM 24/96 au streamer Openhome émulé par Bubbleupnp server sur le Nas qui l'envoie à son tour au streamer réel non Openhome (sauf si on a demandé que le décodage soit fait par Bubbleupnp server, dans ce cas le smartphone n'est plus qu'un simple contrôleur)

Ça veut dire que ton téléphone ne décode pas le fichier.

Tu es donc dans une  config classique UPnP, ton téléphone joue le rôle du contrôler, ton nas le serveur, et ton Streamer le client

Concrètement le serveur met a disposition les fichiers et génére des urls pour chaque fichier.

Le contrôleur choisit le fichier et transmet l'URL au client qui va lire le fichier de l'URL.

Voici les specs Android : un android ne peut pas lire de fichier supérieur a 24/48.

https://developer.android.com/guide/topi...ia-formats

[Nard]

Le paramétrage de Bubbleupnp server sur le Nas indique bien qu'il n'est pas fait de transcodage à ce niveau.

Le paramétrage de Bubbleupnp sous Android indique bien que le décodage est effectué en local par ffmpeg.

Ffmpeg intègre libav qui contient tous les codecs nécessaires.

Mon Dac voit bien arriver du PCM en 96 ou 192kHz.


Je suis donc fondé à penser que le décodage est bien effectué par le smartphone

PS: depuis le début de cette conversation, nous parlons bien de streaming. En ce qui me concerne c'est avec Qobuz. Dans le cas de la médiathèque sur le Nas, la problématique est différente. Le smartphone ne joue alors que le rôle de contrôleur Dlna et le décodage est fait par Minimstreamer avec le ffmpeg du Nas

[comas]

Mais en fait je comprend pas pourquoi on parle de décodage sur téléphone ou Streamer.

C'est le dac qui décode, tous les autres éléments (sauf transcodage souhaité) ne devraient faire que passe plat

[Nard]

Dans le contexte de notre conversation, nous entendions par décodage, l'opération qui consiste à convertir le flac en PCM. J'espère que c'est plus clair maintenant et que tu comprends mieux les différentes possibilités

[comas]

(05-23-2020, 12:21 PM)Nard a écrit : Dans le contexte de notre conversation, nous entendions par décodage, l'opération qui consiste à convertir le flac en PCM. J'espère que c'est plus clair maintenant et que tu comprends mieux les différentes possibilités

Bha du coup c'est au Streamer de faire ça, pas au serveur, ni au controller

[Nard]

Décidément, combien faudra-t-il rabâcher que si cette opération est effectuée par le streamer, on aura davantage de bruit électronique et de jitter ?

[comas]

(05-23-2020, 12:39 PM)Nard a écrit : Décidément, combien faudra-t-il rabâcher que si cette opération est effectuée par le streamer, on aura davantage de bruit électronique et de jitter ?

Et si ça a un impact, c'est que le Streamer est vraiment isolé a la truelle.

Un raspberry 3 n'a pas ce soucis (le cpu ne bosse même pas, le décodage des flux FLAC est fait niveau hardware, comme les flux x264, x265 etc etc).

Le 4 non plus, a la limite on pourrai dire que comme le cpu est cadencé + haut il y aura plus de perturbations, mais suffit de le sous cadencer et voilà.

Bref, on parle de pas grand chose la, le cpu dépassera pas les 5% a tout péter avec du flac.
Si ça suffit a provoquer des ondes électromagnétiques, faut vraiment se poser sur la qualité du Streamer et son isolation

Et pour réduire le jiiter, suffit de passer en USB asynchrone qui a souvent moins de jiiter que le coaxial

[Nard]

Pffff...

Ça n'a rien à voir avec ce que tu dis ! Chaque opération CPU est une commutation de transistors qui modifie le potentiel du plan de masse avec pour conséquence une altération du temps de montée des signaux. Plus il y a de commutations, plus il y a de bruit et de jitter, que cela représente 5% ou 1% des capacités de calcul n'y change rien, c'est la quantité d'opérations qui compte.

Si tu n'entends pas de différence, peut-être devrais-tu t'interroger sur la qualité de ton écoute au lieu de considérer que les autres sont à la ramasse

[comas]

(05-23-2020, 01:06 PM)Nard a écrit : Pffff...

Ça n'a rien à voir avec ce que tu dis ! Chaque opération CPU est une commutation de transistors qui modifie le potentiel du plan de masse avec pour conséquence une altération du temps de montée des signaux. Plus il y a de commutations, plus il y a de bruit et de jitter, que cela représente 5% ou 1% des capacités de calcul n'y change rien, c'est la quantité d'opérations qui compte.

Si tu n'entends pas de différence, peut-être devrais-tu t'interroger sur la qualité de ton écoute au lieu de considérer que les autres sont à la ramasse

Et moi je crois sérieusement qu'on est dans de l'idiophilie la.

Y'a 1 milliards d'autres facteurs du même niveau d'incidence (wifi, 4g, courant, ondes radio, téléphone fixe (qui émet plus d'ondes que le wifi), température, lampes halogènes ou appareil électrique peu isolé, dac ou Streamer posé au dessus d'un ampli avec le transfo de l'ampli, etc etc).

Bref ... Si tu penses que ton nas (qui fait tourner bien plus de chose avec masse de perturbations) ou ton téléphone (qui est pas du tout prévu pour) auront un jiiter meilleur...

Toujours les même débats