Comparaisons Logitech<>UPnP<>Roon<>BluOS

[Pascal64]

J'ai bien essayé chez moi de ruser Roon avec squeeze2upnp , rien à faire, ça rajoute une couche et cela s'entend.

Les solutions UPNP que nous utilisons sur nos PC DIY restent plus performantes que ce qu'on arrive à faire sur la même config via ROON

Je joue avec tous les jours et les differences sont loin d'être subtiles

[ds21]

@n.d.b

LMS en bridge+flow n'a pas été comparée avec LMS en SlimProto sur le même système chez moi, donc je ne peux rien en dire, et avec mon système actuel je ne peux la faire dans de bonnes conditions.

Mais cette comparaison mériterait d'être effectuée? sans à priori...parce que chez moi, l'option bridge+flow me semble bien intéressante quand même.

@Pascal64

Roon+squeeze2upnp avec squeeze2upnp paramétré de la même façon que vous paramétrez Jplayfemto en tant que Control-PC dans fidelizer pro et process lasso et avec MinorityClean donne déjà des résultats très intéressants.

Mais je ne prétends pas que ça concurrence vos solutions avec Jplay/Jplayfemto que je n'ai pas testées et dont je ne sais pas s'il est possible de les utiliser sur la fonction streamer UPnP du Classé sigma?

Cdlt

Edit

Dans les 2 cas j'ai une très bonne dynamique (avec l'ampli Classé FDA), une grande transparence, une scène assez large et profonde avec un positionnement précis des instruments (selon la qualité des enregistrements) et pratiquement pas de dureté dans le haut du spectre ainsi que des basses tendues (FDA) et les timbres des instruments qui sont bien respectés grâce aussi aux enceintes Mulidines.

Je vais tenter de faire la même traitement sur le plugin squeeze2upnp (mêmes paramètres dans fidelizer pro et process lasso que pour Jplayfemto) en utilisation avec LMS sous win10

[bbill]

(10-27-2020, 07:57 PM)bbill a écrit : qu’il faut un système hifi au moins compatible avec deux environnements software (par sécurité, pour comparer, pour compléter les fonctionnalités, etc..)

mais en fait de ces comparaisons, je retiens trois choses :
1.- qu'il faut choisir un lecteur réseau au minimum compatible avec deux environnements software (avec des rares bonnes exceptions comme BlueSound, par exemple, qui même avec un seul soft propriétaire est compatible Roon)
2.- que à hardware identique (et si l'installation est correcte), les différences à l'écoute entre media serveurs et protocole de communication réseau sont +- faibles.. 
3.- qu'il faut parler de configurations complètes pour qualifier les résultats.. rien d'original donc !

ps pour Pascal64 : maintenant que cela est fait (switch, soft serveur, câble RJ45, alimentations,..), je vais m'attaquer à l'optimisation du serveur pour lecteur réseau 

[n.d.b]

@bbill

Oui, tu te rends compte que parler simplement d'une application ne suffit pas à évoquer toutes les possibilités d'un lecteur. Plus il est "natif" sur diverses solutions, plus il a des chances de pouvoir suivre les évolutions.

Pour ton 1 :

Il faut quand même regarder les sorties disponibles. A ce jour un BlueSound ne permet pas d'utiliser les meilleures sorties (I2S, AES) ni la plus à la mode (USB). Là peut-être que le soft est bon, mais c'est un peu dommage de ne pas pouvoir en profiter plus loin.

Il y a tout un tas de propositions propriétaires ou plus ou moins développées sur base RPi ou PC. Il y a 2 intérêts hardware :
- gestion réseau évolutive avec tout ce qu'elle apporte comme possibilité de protocoles (UPnP, RAAT, SlimProto...)
- gestion audio "à part" de la gestion réseau avec toutes les sorties dont on a besoin

C'est pour ça qu'une base Rpi / Hat est assez souple et évolutive.
Sa performance se fera sur
- le développement du HAT (FPGA...) son DAC éventuel et surtout ses horloges, ses sorties, l'asservissement du Rpi...
- l'alimentation du HAT et du Rpi

Une base "PC" bien foutu est aussi évolutive même si plus intégrée (Rose Audio par exemple). C'est bien une solution totalement pensée du point de vue performances, horloges embarquées, gestion de l'alimentation...

L'alimentation fait une bonne partie du prix de la solution (intégrée ou à rajouter)

Par exemple chez Lumin le côté applicatif seul ne peut être l'indicateur de rendu de la solution.
Il faut bien voir le hard, sa partie réseau, sa partie son et son alimentation.
La gamme est faite pour intégrer des améliorations à chaque niveau.

Pour ton 2.

Il va être difficile de parler de hardware identique entre diverses solutions.
Oui on va pouvoir comparer des protocoles au sein d'une même solution, mais encore faut-il qu'ils soient disponibles.

Par exemple tu faisais justement remarquer qu'un 3dlab n'était pas sur la liste officielle des appareils Roon.
Est-ce dire qu'une solution Roon déployée sur le nano n'est pas comparable à une vraie solution Roon/Raat ? C'est possible. Comme il est possible que toute solution déployée sur un autre hardware ne soit qu'adaptative et pas native, c'est à dire passant par un bridge ou un flux UPnP qui n'est pas à proprement parler du "vrai" RAAT ou SlimProto pour ne citer que ces deux là.

3. bien entendu

Et c'est bien le problème dans les échanges puisque nous comparons parfois l'incomparable.
Rien que pour Roon on voit bien qu'il y a un degré de satisfaction énorme chez certains et une déception pour d'autres.
Il faut bien revenir à la configuration et la mise en oeuvre pour savoir s'il n'y a pas eu un problème quelque part.


Enfin j'ai quand même un gros pressentiment quelque part maintenant que j'ai pas mal joué avec diverses solutions.
Et il est que l'USB est peut-être bien le plus gros problème au niveau alimentation. Que son traitement n'est pas simple et que l'intérêt des switch et autres découpleurs a peut-être bien plus à voir avec l'USB qu'avec des sorties nativement propres comme l'I2S et dans une moindre mesure l'AES.

A ce jour j'ai bien l'impression qu'il faut mettre le paquet si on veut un truc satisfaisant en USB et que ça donne au final une solution plus complexe et coûteuse qu'une solution AES et I2S (si possible).

AMHA les pistes à suivre sont
- l'alimentation si possible sans s'embarquer dans un délire de multiplication des devices
- l'asservissement de la partie réseau. Comment éviter qu'un Rpi, une carte propriétaire, un PC ait une influence sur ce qui est en aval. Il y a beaucoup de solutions aval pour rattraper, mais il faut peut-être regarder à la source. Je trouve insatisfaisante par exemple une solution de reclock aval, ou toute autre horloge externe. Ca ne devrait pas être nécessaire et si ça l'est c'est qu'il doit y avoir un problème d'architecture ou de conception quelque part.

[lambrays]

(10-24-2020, 11:15 AM)Nard a écrit :

Citation :ici pour les écoutes, on se limite à un transcodage simple (24:88)

Largement  suffisant pour brouiller l'écoute...

Bonjour 

Le phénomène est encore accentué si l'on fait la comparaison à l'auberge du bon coucher. 
Personnellement j'utilise JRiver sur un Mac Mini relié à un disque dur en USB  de 8 T qui envoie les fichiers en wave dans la carte réseau du DAC audiomat en passant par un Aqvox SE. Le résultat n'est pas mauvais mais certainement améliorable et j'aimerai simplifier cela mais il est difficile de trouver un serveur avec 8 T de SSD qui fonctionnerait avec JRiver. Je ne suis pas tenté par Roon qui me semble être un équivalent Hifi de Itunes ainsi que par les serveurs type Grimm qui reformatent les fichiers dans des définitions à leur mode et qui soit transforment tous les fichiers PCM en DSD ou font l'inverse.

[mélaudiophile]

Salut, déjà 6 pages et j'ai peut-être loupé quelque chose, mais je voudrais savoir quel est le protocole qui permet de passer du DSD 128, ISO ou dsf, à un DAC acceptant ça en natif? Et même est-ce possible en réseau?
Le fait de faire la comparaison en 16/44 ou 24/88 n'éclairera pas sur ce point, qui peut avoir de l'importance si on possède beaucoup de fichiers de ce type, ce qui est mon cas.

[SuperDupont]

(10-28-2020, 01:34 PM)Pascal64 a écrit : J'ai bien essayé chez moi de ruser Roon avec squeeze2upnp , rien à faire, ça rajoute une couche et cela s'entend.

Les solutions UPNP que nous utilisons sur nos PC DIY restent plus performantes que ce qu'on arrive à faire sur la même config via ROON

Je joue avec tous les jours et les differences sont loin d'être subtiles

Clairement. Pour ceux qui s'interrogent sur un eventuel resampling, cela n'a pas d'incidence sur cet ecart constaté sur diverses configurations chez moi et ailleurs. Les tests effectués avec et sans resampling conduisent au meme resultat.

(10-29-2020, 12:11 PM)mélaudiophile a écrit : Salut, déjà 6 pages et j'ai peut-être loupé quelque chose, mais je voudrais savoir quel est le protocole qui permet de passer du DSD 128, ISO ou dsf, à un DAC acceptant ça en natif?  Et même est-ce possible en réseau?
Le fait de faire la comparaison en 16/44 ou 24/88  n'éclairera pas sur ce point, qui peut avoir de l'importance si on possède beaucoup de fichiers de ce type, ce qui est mon cas.

Avec quel soft? Coté LMS, pour sortir en dsd natif, il faut installer le plugin DSD player et pour jouer avec les resampling PCM/DSD, c'est le plugin C-3PO transcoding helper qui s'en charge https://forums.slimdevices.com/showthrea...ing-helper

[bbill]

(10-29-2020, 02:21 PM)SuperDupont a écrit : Pour ceux qui s'interrogent sur un eventuel resampling, cela n'a pas d'incidence sur cet ecart constaté sur diverses configurations chez moi et ailleurs. Les tests effectués avec et sans resampling conduisent au meme resultat.

oui, cela dépend des configurations, sur certaines configurations, cela s'entend de façon évidente

[SuperDupont]

(10-29-2020, 03:03 PM)bbill a écrit :

(10-29-2020, 02:21 PM)SuperDupont a écrit : Pour ceux qui s'interrogent sur un eventuel resampling, cela n'a pas d'incidence sur cet ecart constaté sur diverses configurations chez moi et ailleurs. Les tests effectués avec et sans resampling conduisent au meme resultat.

oui, cela dépend des configurations, sur certaines configurations, cela s'entend de façon évidente

Je parle francais pourtant: je parle de l'ecart entre roon et d'autres softs, qu'il y ait du resampling ou NON.

[bbill]

(10-29-2020, 04:19 PM)SuperDupont a écrit :

(10-29-2020, 03:03 PM)bbill a écrit :

(10-29-2020, 02:21 PM)SuperDupont a écrit : Pour ceux qui s'interrogent sur un eventuel resampling, cela n'a pas d'incidence sur cet ecart constaté sur diverses configurations chez moi et ailleurs. Les tests effectués avec et sans resampling conduisent au meme resultat.

oui, cela dépend des configurations, sur certaines configurations, cela s'entend de façon évidente

Je parle francais pourtant: je parle de l'ecart entre roon et d'autres softs, qu'il y ait du resampling ou NON.

la question qui avait été posée plus haut, comment configure-t-on les différents softs serveur notamment le DSP afin que la comparaison soit valable, il y a des différences.. je n'avais pas vu ici de réponses évidentes