Démat' : streamer VS serveur

[r11bordo]

(04-28-2019, 03:52 PM)Bigga a écrit : Personnellement, je suis en liaison Wifi entre serveur et player, et cela fonctionne parfaitement en 16/44,1, mais pose parfois des problèmes de lecture intermittente en lecture locale de fichiers Hi Res (AIFF en 24/96 ou plus, ou DSD). 

Cette réponse ne laisse aucune ambiguïté. Une liaison client serveur en WiFi pour l'audio ne fonctionne donc pas ...

Perso, je suis en liaison filaire avec streamer et serveur séparés afin de dédier la lecture des pistes sur une machine dédiée et le décodage des pistes sur une autre machine. Les optimisations du système sur le streamer ne sont pas forcément compatible avec celle d'un serveur (exemple l'activation du Réal Time sur un rpi3 n'est pas compatible avec l'exécution d'un LMS par exemple alors que cette option est bénéfique pour le décodage des pistes).

[Bigga]

(05-02-2019, 03:54 PM)r11bordo a écrit :

(04-28-2019, 03:52 PM)Bigga a écrit : Personnellement, je suis en liaison Wifi entre serveur et player, et cela fonctionne parfaitement en 16/44,1, mais pose parfois des problèmes de lecture intermittente en lecture locale de fichiers Hi Res (AIFF en 24/96 ou plus, ou DSD). 

Cette réponse ne laisse aucune ambiguïté. Une liaison client serveur en WiFi pour l'audio ne fonctionne donc pas ...

Perso, je suis en liaison filaire avec streamer et serveur séparés afin de dédier la lecture des pistes sur une machine dédiée et le décodage des pistes sur une autre machine. Les optimisations du système sur le streamer ne sont pas forcément compatible avec celle d'un serveur (exemple l'activation du Réal Time sur un rpi3 n'est pas compatible avec l'exécution d'un LMS par exemple alors que cette option est bénéfique pour le décodage des pistes).

Ben si, ça fonctionne très bien, en ce moment même d'ailleurs, sur les fichiers 16/44,1, c'est à dire issus de rips de CD. Autant dire, quand même, la grand majorité des fichiers que les utilisateurs possèdent.
Après, sur la haute résolution, parfois ça merdouille, et bien sur il faut que le wifi fonctionne bien, ce qui chez moi ne pose que très rarement des problèmes.
Donc, pour une liaison audio quand on écoute du 16/44,1, une liaison Wifi fonctionne parfaitement. Après, idéalement, la liaison filaire est plus stable et sa bande passante potentiellement plus importante, évidemment, mais quand on peut pas faire autrement... Et je galère encore avec le pontage du Wifi du RPi vers son Ethernet. Impossible de le faire fonctionner chez moi pour l'instant.
En revanche, je suis bien d'accord que la séparation serveur et player est un plus pour l'optimisation aux petits oignons des 2. Même si un kernel temps réel n'est peut être pas la priorité de quelqu'un qui débute son installation démat.

[r11bordo]

Bah autant démarrer par un montage cohérent avec la hifi, sauf si on veut sonoriser sa cuisine ou sa salle de bain.

[ttd.fornotlife]

(05-02-2019, 06:23 PM)Bigga a écrit :

(05-02-2019, 03:54 PM)r11bordo a écrit :

(04-28-2019, 03:52 PM)Bigga a écrit : Personnellement, je suis en liaison Wifi entre serveur et player, et cela fonctionne parfaitement en 16/44,1, mais pose parfois des problèmes de lecture intermittente en lecture locale de fichiers Hi Res (AIFF en 24/96 ou plus, ou DSD). 

Cette réponse ne laisse aucune ambiguïté. Une liaison client serveur en WiFi pour l'audio ne fonctionne donc pas ...

Perso, je suis en liaison filaire avec streamer et serveur séparés afin de dédier la lecture des pistes sur une machine dédiée et le décodage des pistes sur une autre machine. Les optimisations du système sur le streamer ne sont pas forcément compatible avec celle d'un serveur (exemple l'activation du Réal Time sur un rpi3 n'est pas compatible avec l'exécution d'un LMS par exemple alors que cette option est bénéfique pour le décodage des pistes).

Ben si, ça fonctionne très bien, en ce moment même d'ailleurs, sur les fichiers 16/44,1, c'est à dire issus de rips de CD. Autant dire, quand même, la grand majorité des fichiers que les utilisateurs possèdent.
Après, sur la haute résolution, parfois ça merdouille, et bien sur il faut que le wifi fonctionne bien, ce qui chez moi ne pose que très rarement des problèmes.
Donc, pour une liaison audio quand on écoute du 16/44,1, une liaison Wifi fonctionne parfaitement. Après, idéalement, la liaison filaire est plus stable et sa bande passante potentiellement plus importante, évidemment, mais quand on peut pas faire autrement... Et je galère encore avec le pontage du Wifi du RPi vers son Ethernet. Impossible de le faire fonctionner chez moi pour l'instant.
En revanche, je suis bien d'accord que la séparation serveur et player est un plus pour l'optimisation aux petits oignons des 2. Même si un kernel temps réel n'est peut être pas la priorité de quelqu'un qui débute son installation démat.

Le kernel RT n’est pas une difficulté notamment sur du Pi quand on prend des ad’hoc comme Ropieee, PicorePlayer, audiolinux. C’est proposé d’entree De jeu.

[Bigga]

(05-02-2019, 08:49 PM)ttd.fornotlife a écrit :

(05-02-2019, 06:23 PM)Bigga a écrit :

(05-02-2019, 03:54 PM)r11bordo a écrit :

(04-28-2019, 03:52 PM)Bigga a écrit : Personnellement, je suis en liaison Wifi entre serveur et player, et cela fonctionne parfaitement en 16/44,1, mais pose parfois des problèmes de lecture intermittente en lecture locale de fichiers Hi Res (AIFF en 24/96 ou plus, ou DSD). 

Cette réponse ne laisse aucune ambiguïté. Une liaison client serveur en WiFi pour l'audio ne fonctionne donc pas ...

Perso, je suis en liaison filaire avec streamer et serveur séparés afin de dédier la lecture des pistes sur une machine dédiée et le décodage des pistes sur une autre machine. Les optimisations du système sur le streamer ne sont pas forcément compatible avec celle d'un serveur (exemple l'activation du Réal Time sur un rpi3 n'est pas compatible avec l'exécution d'un LMS par exemple alors que cette option est bénéfique pour le décodage des pistes).

Ben si, ça fonctionne très bien, en ce moment même d'ailleurs, sur les fichiers 16/44,1, c'est à dire issus de rips de CD. Autant dire, quand même, la grand majorité des fichiers que les utilisateurs possèdent.
Après, sur la haute résolution, parfois ça merdouille, et bien sur il faut que le wifi fonctionne bien, ce qui chez moi ne pose que très rarement des problèmes.
Donc, pour une liaison audio quand on écoute du 16/44,1, une liaison Wifi fonctionne parfaitement. Après, idéalement, la liaison filaire est plus stable et sa bande passante potentiellement plus importante, évidemment, mais quand on peut pas faire autrement... Et je galère encore avec le pontage du Wifi du RPi vers son Ethernet. Impossible de le faire fonctionner chez moi pour l'instant.
En revanche, je suis bien d'accord que la séparation serveur et player est un plus pour l'optimisation aux petits oignons des 2. Même si un kernel temps réel n'est peut être pas la priorité de quelqu'un qui débute son installation démat.

Le kernel RT n’est pas une difficulté notamment sur du Pi quand on prend des ad’hoc comme Ropieee, PicorePlayer, audiolinux. C’est proposé d’entree De jeu.

Ce que je voulais dire, c’est que ce n’est pas la priorité de notre ami, à mon sens.
Par ailleurs, sous Picoreplayer, il me semble que c’est assez récent non?
Quoi qu’il en soit, le kernel RT pose des difficultés, comme le disait R11bordo, si on veut faire tourner en même temps LMS. C’est ce qu’ont relaté certains sur le fil du Mano, qui pourtant faisait tourner parfaitement une version non RT avec LMS chez moi.
Mais, pour revenir à nos moutons, la liaison wifi, si elle n’est pas idéale en théorie, et présente quelques limites, n’est pas une solution de sonorisation de cuisine ou salle de bains plus qu’autre chose. Cela marche très bien quand on a pas le choix du filaire, et il n’y a pas à mépriser le résultat, sincèrement.
Et puis, au début, ça permet de tester une solution à serveur séparé du player sans se poser de questions quant aux pollutions réseaux...

[r11bordo]

(05-02-2019, 09:26 PM)Bigga a écrit : Ce que je voulais dire, c’est que ce n’est pas la priorité de notre ami, à mon sens.
Par ailleurs, sous Picoreplayer, il me semble que c’est assez récent non?
Quoi qu’il en soit, le kernel RT pose des difficultés, comme le disait R11bordo, si on veut faire tourner en même temps LMS. C’est ce qu’ont relaté certains sur le fil du Mano, qui pourtant faisait tourner parfaitement une version non RT avec LMS chez moi.

Le mode RT n'est pas récent. Les Squeezebox Touch de 2010 je crois utilisaient déjà un noyau Linux compilé en mode RT, sous Squeeze OS.

[Bigga]

(05-02-2019, 09:56 PM)r11bordo a écrit :

(05-02-2019, 09:26 PM)Bigga a écrit : Ce que je voulais dire, c’est que ce n’est pas la priorité de notre ami, à mon sens.
Par ailleurs, sous Picoreplayer, il me semble que c’est assez récent non?
Quoi qu’il en soit, le kernel RT pose des difficultés, comme le disait R11bordo, si on veut faire tourner en même temps LMS. C’est ce qu’ont relaté certains sur le fil du Mano, qui pourtant faisait tourner parfaitement une version non RT avec LMS chez moi.

Le mode RT n'est pas récent. Les Squeezebox Touch de 2010 je crois utilisaient déjà un noyau Linux compilé en mode RT, sous Squeeze OS.

Aucune idée, mais je n’ai pas parlé du mode RT dans l’absolu, mais sous pcp précisément.
D’une manière générale, les propos, c’est mieux quand on les déforme pas...

[r11bordo]

Ce que je veux dire à l'ami qui a ouvert le post, s'il souhaite juste avoir de la musique dans sa cuisine ou sa salle de bain, il peut mélanger serveur et streamer sur la même machine. 
S'il souhaite démarrer un système hi-fi de salon, il est toutefois préférable, amha, de séparer les deux fonctions pour les relier en filaire.

[ttd.fornotlife]

(05-03-2019, 12:00 AM)Bigga a écrit :

(05-02-2019, 09:56 PM)r11bordo a écrit :

(05-02-2019, 09:26 PM)Bigga a écrit : Ce que je voulais dire, c’est que ce n’est pas la priorité de notre ami, à mon sens.
Par ailleurs, sous Picoreplayer, il me semble que c’est assez récent non?
Quoi qu’il en soit, le kernel RT pose des difficultés, comme le disait R11bordo, si on veut faire tourner en même temps LMS. C’est ce qu’ont relaté certains sur le fil du Mano, qui pourtant faisait tourner parfaitement une version non RT avec LMS chez moi.

Le mode RT n'est pas récent. Les Squeezebox Touch de 2010 je crois utilisaient déjà un noyau Linux compilé en mode RT, sous Squeeze OS.

Aucune idée, mais je n’ai pas parlé du mode RT dans l’absolu, mais sous pcp précisément.
D’une manière générale, les propos, c’est mieux quand on les déforme pas...

...Ou quand on ne fait pas des amalgames rapides. Ce n’est pas le mode RT qui limite l’utilisation de picoreplayer en server mais le raspberry pi. Un serveur demande plus de ressources qu’un streamer qui pousse de la data comme avec Roon ou qui décode comme en UPnP/LMS.
Il me semble que ceux qui utilisent audiolinux sur base archlinux en RT et serveur sont très content : sur un vrai serveur.

---

(05-03-2019, 12:43 AM)r11bordo a écrit : Ce que je veux dire à l'ami qui a ouvert le post, s'il souhaite juste avoir de la musique dans sa cuisine ou sa salle de bain, il peut mélanger serveur et streamer sur la même machine. 
S'il souhaite démarrer un système hi-fi de salon, il est toutefois préférable, amha, de séparer les deux fonctions pour les relier en filaire.

Oui +1.

[r11bordo]

Ce sont plutôt les logiciels serveurs type LMS ou minimserver qui semblent mal s'exécuter sur un noyau RT. Un rpi3 peut largement supporter un LMS. Le mien est hébergé sur un NAS Qnap TS-131 qui ne représente que la moitié d'un rpi3 en terme d'architecture (bicore ARM, freq 1ghz, 500Mo de RAM), et j'arrive à transcoder des formats audios jusqu'au 24/192 sans mettre la machine à genoux. En revanche, cela devrait ne pas passer avec du dsd.