Forum Linux.général MPD + webradio : déporter le transcodage sur une machine plus puissante.

Posté par . Licence CC by-sa
Tags : aucun
2
16
oct.
2015

Bonjour à tous,

Voilà la bidouille du moment :
Chez moi j'ai un NAS, (avec un ARM quelconque monocore, 1Ghz), qui me sert entre autre de serveur de musique.
Un hybride avec une interface web perso qui contrôle un mpd sous jacent, sortie sur un DAC USB qui arrose ma maison de bonne vibrations… Jusque là, tout va bien.

Mais l'idée farfelue arrive, pouvoir faire écouter à quelqu'un à l'extérieur ce que j'écoute, de façon un peu plus évolué qu'en approchant le téléphone des enceintes.
Fastoche!!
MPD fait ça comme un grand, suffit d'activer une sortie httpd (ou shoutcast), et d'ouvrir le bon port réseau, et roule ma poule.

Oui mais non. Le CPU du NAS est à genoux dès que je lance le stream http. A vue de nez un bon 200% de charge => la lecture est interrompue 50% du temps.
J'ai essayé avec encodeur vorbis et lame, pas mieux. Essayé de baisser le bitrate, pas mieux.

Alors voilà mon idée, comme c'est un usage relativement ponctuel, je pensais déporter le transcodage sur un CPU un peu plus balèze, mais sans tout casser de mon architecture NAS qui me va bien pour tout le reste.

Donc j'imaginais dans le MPD qui tourne sur le NAS activer une sortie qui balance sur le LAN, un flux en wave (donc pas de transcodage complexe), soit par pulseaudio, ou shout, ou que sais-je couche de transport.

Et sur mon pc avec le CPU qui va bien, faire tourner un serveur qui prend le flux arrivant de mpd, et le transcode en mp3 à disposition d'un client http.

Je voulais m'inspirer de ça…
http://linuxfr.org/users/soulfly_b/journaux/rediriger-une-sortie-audio-vers-un-serveur-de-streaming

Mais voilà, je suis un peu perdu, je patauge entre les rôles de icecast, gstreamer, pulseaudio, etc …..

Que pensez vous de l'architecture? Comment vous feriez au plus simple?

(pendant ce temps je réfléchis, pas dit que j'arrive pas entre temps avec une solution….)

d'avance merci, Pierre

PS : le NAS fait tourner une debian 7, et le pc lourd une ubuntu 14.04.

  • # sortie http != sortie shoutcast

    Posté par . Évalué à 2.

    Si tu actives la sortie shoutcast dans MPD au lieu de http, il n'enverra pas le flux directement, tu peux alors utiliser icecast (clone libre de shoutcast) pour transformer la sortie de MPD en flux http. Ce icecast peut très bien être sur une autre machine.
    C'est la méthode à l'ancienne, MPD ayant ensuite rajouté la sortie http directement.

    En revanche, je ne connais pas plus le détail, et je ne sais pas si MPD ne fait pas déjà un encodage à la volée pour balancer le flux à icecast (qui réencode lui-même différemment ensuite s'il ne l'a pas dans son format de sortie). Et s'il le fait, je ne sais pas quel encodage est le plus couteux.

    En y repensant, je faisais tourner MPD+icecast sur fit-PC2 (Atom Z510 1 GHz, 1Go RAM). J'avais parfois des coupures et ait toujours accusé bêtement la bande passante (derrière un ADSL). Peut-être que quand je l'ai migré ça marchait mieux simplement parce que le nouveau serveur était plus puissant.
    Celà dit, même sur l'ancien, il y avait des moments où ça marchait très bien. Peut-être l'encodage au niveau des fichiers a-t-il une influence ?

  • # Et avec du savon ?

    Posté par (page perso) . Évalué à 2.

    Je ne sais pas si ça va résoudre ton problème spécifique, mais quand on cause streaming de sons, j'ai vite tendance à regarder du coté de liquidsoap, outil méconnu, délicat à utiliser, mais clairement efficace.

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # ça glisse...

      Posté par . Évalué à 1.

      Merci à vous deux pour les réponses, pertinentes qui plus est.

      Hypothèse A, MPD agit en tant que client source shout/icecast.
      Pour mon scénario, ça ne marche pas, pour deux raisons, une qui se solutionnerait en plongeant dans le code de mpd, l'autre plus dure.
      La couche shoutcast de mpd ne permet de sortir en wave. Si j'active le mp3 ou ogg, je tourne en rond, le cpu n'y arrive pas.
      Je pense pas qu'il y en ait pour des semaines de taf pour modifier ça.
      Mais là où ca coince un peu plus, c'est qu'en faisant des essais avec ezstream, icecast ne semble pas accepter en entrée du wave, et en tout cas, j'ai cru comprendre que son rôle n'était de toute façon pas de transcoder.
      Donc exit.

      Hypothèse B, liquidsoap.
      Un peu sceptique au début.
      Mais en fait c'est une arme de guerre. Totalement conquis.
      Il fait le taf, bien, et facilement en plus!

      En version courte l'archi choisie :

      MPD, avec sortie HTTP activée, en encodage wave (la doc ne dit pas le supporter, mais si si). Attention juste, dans ma version de mpd, bizarrement la sortie était en mono…..

      Ça déjà, lu pas un vlc, c'est nickel, le cpu du nas est heureux.

      Sur la machine avec du CPU, le couple liquidsoap/icecast.
      liquidsoap se connecte au flux wave/http de mpd, le transcode en mp3 et pousse ça vers icecast
      icecast en config par défaut.

      Pour info, icecast et liquidsoap sont dans les dépôts d'ubuntu. Facile j'ai dit.

      Bon, il y a juste que le savon ça fait des bulles. Au changement 'naturel' de piste (enchainement de playlist de mpd) la piste suivante se met à complètement bugger (des glitch comme disent les anglophones) Si je fais pause et remet lecture, ça repart ok, mais bon pas top. J'ai bien l'intention de trouver le soucis.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.