MPD est finalement assez peu connu et pourtant, dans le cadre d'une architecture domestique, il répond au besoin récurrent des mélomanes qui aiment à donner une ambiance musicale différente à chacune de leurs pièces. L'objectif de ce tutoriel est de vous proposer une simple "mise en scelle", le monde MPD étant juste une vaste trop pour le couvrir d'une seul passe...
Qu'est-ce que MPD ?
MPD (Music Player Daemon) c'est :
- Un lecteur audio multi-formats entièrement contrôlable à travers le réseau.
- Un explorateur d'audiothèques capable de stocker les étiquettes (ID3 & co.) de vos morceaux dans une base de donéne et d'y effectuer des recherches.
- Un gestionnaire de liste de lecture (playlist).
A l'inverse,
- MPD n'est pas un lecteur de vidéo, diapos & co.
- MPD ne dispose pas d'une belle interface.
- MPD n'embarque pas de serveur WEB/AJAX.
- MPD n'est absolument pas sexy et n'impressionnera jamais vos amis.
En somme, MPD n'a (à mon sens) d'intérêt que dans trois cas de figure :
- Lorsque l'on a chargé une machine sans écran, ni clavier de la sonorisation d'un espace.
- Lorsque plusieurs personnes sont amenées à prendre la main sur la musique diffusée, chacune avec un outil différent.
- Lorsque l'on désire diffuser de l'audio en mode "shoutcast", via Icecast (ce n'est pas le sujet de ce tutoriel cependant).
Mise en oeuvre
Installation
Là, rien de très sorcier. MPD est sans aucun doute déjà dans votre distribution. Un coup d'urpmi mpd ou d'apt-get install mpd devrait suffire à installer le serveur. Ensuite tout ce passe dans le fichier /etc/mpd.conf.
Les fichiers audio
Pour que MPD puisse fonctionner, il lui faut... de la musique et peu importe, ou presque, le format. MPD peut lire les fichier mp3, mp2, ogg, flac, wav, au, aiff, aif, mpc, amf, dsm, far, gdm, imf, it, med, mod, mtm, s3m, stm, stx, ult, uni et xm. Il existe même une version plus "underground" lisant les AAC (dispo sur le dépôt PLF pour les mandriva il me semble).
Les fichiers audio doivent être accessible en local par MPD. Si vous avez plusieurs instances, vous la placerez donc dans un dossier partagé, par exemple NFS. Dans la suite du tutoriel, nous partirons du principe que vos morceaux se trouver dans le dossier /musique.
Dans le fichier /etc/mpd.conf, il vous faut repérer un bloc ressemblant à cela
music_directory "~/music"
playlist_directory "~/playlists"
db_file "/var/lib/mpd/mpd.db"
Il s'agit de tous les chemins dont a absolument besoin MPD pour fonctionner. La première ligne correspond à la source de fichier audio, nous remplaçons donc comme suit :
music_directory "/musique"
La seconde ligne correspond au dossier dans lequel MPD lit et écrit les listes de lectures (fichiers .m3u au format WinAmp). Comme il est sympa de pouvoir partager ces listes entre tous les serveurs MPD, le plus simple est de créer un sous-dossier /musique/mdp :
playlist_directory "/musique/mdp"
Ensuite vient la base de donnée qui contiendra les chemins, les étiquettes, bref, tout ce que MPD découvrira dans le dossier /musique. Là aussi, il est pratique qu'elle soit partagé car ainsi la création et la mis à jour de cette base sur une machine, sera effective sur toutes les autres :
db_file "/musique/mdp/mdp.db"
Petit cas de droit
Maintenant la partie un peu funky. Un peu plus loin dans le fichier vous devez trouvez quelque chose comme cela :
user "mpd"
L'idée est que lancer MPD en tant que root, c'est comme croiser les flux, c'est mal. Donc à l'installation du paquet, un gentil utilisateur mpd bien inoffensif a été créé. Et en toute logique cette utilisateur là n'a aucun droit de lecture, et encore moins d'écriture dans votre dossier /musique.
Je ne vais pas rentrer plus avant dans la manière de régler ce "problème" car chacun a son approche. Personnellement j'ai opté pour la création d'un groupe "acces-audio" qui a le même ID sur toutes mes machines. L'utilisateur MPD appartient à ce groupe. Et tout le dossier musique appartient lui aussi à ce groupe en lecture, et en écriture sur le dossier /musique/mpd.
Vous pouvez aussi prendre la posture barbare du chmod g+rwX /musique mais à ce moment là, autant dire à MPD d'utiliser "root" comme utilisateur...
Enfin, vous pouvez utiliser le fait que l'utilisateur mpd appartient généralement au groupe audio et du coup attribuer ce groupe au dossier /musique comme je le fait pour mon acces-audio.
Bref, c'est ici une histoire de goût et le point important est que l'utilisateur qui lance MPD puisse lire dans /musique et écrire dans /musique/mpd, et ce sur toutes les machines où il doit être lancé.
Sorties Audio
MPD est conçu de sorte à pouvoir gérer en simultané plusieurs sorties audio. Il est donc possible avec plusieurs cartes audio de distribuer la même musique sur plusieurs pièces à partir d'un seul serveur. La majorité des clients MPD permettent d'activer ou de désactiver telle ou telle sortie à distance.
Une sortie MPD peut utiliser les pilotes ALSA ou OSS, les serveurs audio Jack ou Pulse, ou encore un serveur de type ShoutCast. Et si cela ne suffit pas, vous pouvez passer par libao qui permet d'attraper un serveur ESD par exemple.
Dans notre cas, faisons simple. Déjà si vous avez Pulse d'installé, personnellement je le virerait... Cela se fait très facilement sur une Mandriva en passant par Drakconf. Pulse est bien sympa sur l'idée mais je ne vois pas bien son intérêt en local.
Nous allons donc utiliser une toute classique périphérique audio en utilisant ALSA. Pour cela il faut aller jeter un oeil un peu plus loin dans le fichier de configuration et chercher les sections nommées audio_output. Si vous en avez aucune ou si elles sont toutes commentées, ajoutez ce qui suit, sinon vérifiez que ça ressemble un peu à cela :
audio_output {
type "alsa"
name "Sortie vers Chambre"
}
Si je vous avez une deuxième carte audio, vous pouvez donc ajouter une seconde sortie :
audio_output {
type "alsa"
name "Sortie vers Buanderie"
device "hw:0,1"
}
Notez le paramètre device qui indique que le tape sur le deuxième périphérique ALSA (le premier étant sous entendu dans la première sortie comme étant hw:0,0).
A ce stade certain peuvent se demander pourquoi ne pas utiliser plutôt un ou plusieurs serveurs, de type ESD ou Pulse sur les machines qui diffuse physiquement l'audio. Si c'est faisable, la réponse est "est-ce rentable ?". Car enfet, cela revient à transbahuter un signal PCM sûrement un peu compressé sur mon réseau. Avec MPD, j'utilise un partage (NFS, CIFS, etc.) qui transporte des fichiers compressés en OGG ou en MP3... D'un point de vue occupation de bande passante je suis clairement gagnant dans le second cas. Pulse & co ont sûrement un usage, mais je ne pense pas que ce soit celui-là. Et c'est à peu prés la même chose pour diffuser du shoutcast. C'est sûrement très bien pour des utilisations de votre musique en extérieur (genre ce que permet Ampache), mais pour des amplis fixes, je ne vois pas bien l'intérêt...
Dernier aspect, le contrôle du volume. Comme pour les sorties audio, vérifiez que les lignes suivantes existent, ne sont pas commentées et concordent bien :
mixer_type "alsa"
mixer_device "default"
mixer_control "Master"
On utilise ici la table de mixage ALSA du périphérique par défaut (hw:0,0) dont on utilise le canal Master.
Paramétrage réseau
Dernière chose à faire : rendre notre serveur visible sur notre réseau local. Imaginons pour cela que notre machine ait pour adresse IP 10.0.0.10, nous modifierons donc la configuration dans ce sens :
bind_to_address "10.0.0.10"
port "6600"
Reste maintenant à démarrer notre serveur par un /etc/init.d/mpd start.
Base de donnée
MPD est capable de lire tous les attributs contenus dans les fichiers audio (ID3, vorbis, etc) de sorte constituer une base de donnée de recherche de morceaux qui sera utilisée lors de la navigation. A la première utilisation, il nous faut donc initialiser cette base de donnée. Pour cela, lancez la commande suivante :
mpd --create-db
MPD doit alors cracher un flot continu de texte listant les fichiers audio qu'il est en train de disséquer. Tout dépends de votre audiothèque, chez moi cette opération prend prés de 5 minutes. C'est une des raisons qui m'a amené à partager la base de données entre les différentes serveurs...
Notez cependant que cette opération n'est à réaliser qu'une seule fois. Par la suite il suffira d'une simple mise à jour de la base.
Les clients
Maintenant que notre serveur est en route, il est temps de lui envoyer des commandes. Pour cela, il nous faut un client et là, le choix est vaste. Mais avant de commencer à en explorer quelques un, regardons de plus prés comment le serveur MPD cause avec ses clients.
Le protocole MPD
MPD est un simple serveur Telnet... Pour s'en convaincre, essayez ceci :
root#telnet mon_serveur_mpd 6600Trying 10.0.0.10...Connected to mon_serveur_mpd (10.0.0.10).Escape character is '^]'.OK MPD 0.13.0pingOKlist albumAlbum: #51Album: 7th Ave. StrollAlbum: A Clockwork OrangeAlbum: A Day Without Rain...OKcloseConnection closed by foreign host.root#
Avec un protocole aussi trivial, on comprend mieux qu'il existe une librairie MPD pour à peu prés tout les langages. Pour ceux que cela intéresse le protocole est complètement documenté ici.
Ligne de commande
Hum, sympa, ce qu'elle écoute, je vais le mettre ici
:
#! /bin/sh
# on définit le nom de la machine où tourne le serveur source
export MPD_HOST=$1
# on récupère la piste en cours de lecture
track=$(mpc | grep playing | awk '{print $2}' | cut -d"/" -f 1 | tr "#" " ")
# on récupère la position dans la piste
position=$(mpc | grep playing | awk '{print $3}' | cut -d "/" -f1)
# on vire une éventuelle liste de lecture "tmp"
mpc rm tmp
# on sauve la liste de lecture en cours dans "tmp"
mpc save tmp
# on se place maintenant sur le serveur cible
export MPD_HOST=$2
# on vire la liste de lecture en cours
mpc clear
# on charge la liste "tmp" créée plus haut
mpc load tmp
# on sélectionne le morceau
mpc play $track
# et on se déplace sur la position, la lecture démarre...
mpc seek 00:$position/usr/bin/synchronize-mpd.sh
Et voilà, il suffit alors de lancer
synchronize-mpd.sh serveur_chambre serveur_salon
Et hop, les deux serveurs sont synchorisés sur la même liste, lisent le même morceau à la même position. Des petits délires de ce genre, vous pouvez en trouver des tonnes ici.
Pour une version plus graphique, il existe aussi un client nCurse (cf. photo)
Clients graphiques
Avec Sonata, mais c'est vrai pour la majorité des clients, toutes les opérations MPD sont disponibles, de l'exploration des morceaux à la constitution de la liste de lecture courrante, son stockage sur le disque, etc. Sonata rivalise avec Rythmbox en téléchargeant les paroles, les pochettes, etc.
La première chose à faire pour utiliser Sonata, et c'est le cas pour tous les clients qui suivent, est de se connecter au serveur MPD. Pour cela, il suffit de faire sur l'interface un click-droit/préférences... pour, dans l'onglet serveurs, ajouter vos différents noms de machines hébergeant une instance de MPD. Ceci fait, il suffit de refaire un click-droit/connexion et de sélectionner le serveur que l'on cherche à contrôler. Le reste est suffisament proche d'un lecteur audio classique pour que vous vous en sortiez sans problèmes.
Pour plus de clients graphiques, allez ici...
Les extensions
Une extension que j'aime particulièrement est celle pour FireFox. Il permet ainsi, sans serveur WEB, de contrôler plusieurs serveurs MPD en utilisant une interface assez propre. La dernière Alpha fonctionne sur FireFox3. Un fois l'extension installée et firefox redémarré, regardez dans les icônes de la barre de status, en bas à droite.
Pour plus d'extensions, allez ici...
Les clients WEB
Tout d'abord il y a l'excellente application PHP/AJAX, pitchfork. Elle fonctionne parfaitement dés lors que l'on dispose d'un écran de bonne taille. Pour de plus petits apareils comme l'iPhone, il existe aussi ipodmp.tgz.
Dans tous les cas, il vous faudra bien évidement un serveur apache, le module mod-php qui va bien et un peu de paramétrage pour que tout cela fonctionne. Le seul inconvénient de ces deux applications WEB, c'est qu'elles ne disposent que d'une seule configuration. Il faut donc dupliquer le contrôle de chaque serveur MPD sur une URL différente.
Pour plus d'applications WEB, allez audioscrobbler ou last.fm. Pour une liste complète de ce type de clients, allez ici.
Nous avons aussi les clients qui permettent de contrôler MPD par joystick ou une télécommande IR. D'écrire sur un afficheur LCD ou de contrôler le système par une unité
Les WebRadios
Il est possible avec MPD d'ajouter des fichiers qui ne sont pas sur le serveur local mais sur un serveur HTTP. C'est typiquement le cas des listes de lecture et flux des webRadios. Prenons l'exemple de BFM radio dont l'URL est http://cache.yacast.fr/V4/bfm/bfm.m3u.
Pour l'utiliser, soit vous l'ajoutez dans l'onglet flux de Sonata, soit vous allez dans votre dossier /musiques/mpd qui contient les liste de lecture et vous la téléchargez :
wget http://cache.yacast.fr/V4/bfm/bfm.m3u
Ensuite il ne vous reste plus qu'à vous connecter sur le serveur avec Sonata et à double-clicker sur la liste Pour accéder à la radion.
Et avec mpc, vous feriez comme ceci :
export MPD_HOST=mon_serveur_mpd
mpc clean
mpc load bfm
mpc play
Notez au passage que France Intox c'est grandement amélioré par rapport à la dernière fois où j'avais testé cette radio publique sur un système libre. Maintenant toute les radios de Radio France, sont disponible en
Il est donc possible de diffuser une webRadio sans problème avec MPD tant qu'il s'agit d'un flux compatible avec ce que connait le démon (MP3/OGG) et que cela passe par du HTTP. Du coup, je n'ai pas trouvé de moyen sans passer par une usine à Gaz de transcodage, d'utiliser les flux RTSP/MPeg2 des radios de la FreeBox en multi-poste.
MPC et FreeBox HD
Voir cet article si ce type de montage vous intéresse.
Conclusion
Partant d'une définition très simple de "serveur musicale contrôlable à distance", MPD a permis le développement d'un écosystème d'une rare richesse. Et tant que l'on reste dans le cadre de ce pour quoi ce serveur est fait, il est difficile de ne pas trouver client à son pied, ou de ne pouvoir le scripter pour un comportement particulier. C'est bien simple, aujourd'hui MPD est tellement rentré dans notre quotidien qu'ici, personne ici ne pourrait plus s'en passer.
Je ne pense pas. L'avantage de l'uPNP est surtout son adoption par énormément d'acteur sur le marché. Il y a maintenant des télés avec control point upnp/dlna intégré, et même si ce n'est pas génial pour faire évoluer le software, ca permet d'économiser un poste. (Bien sûr, vu que je suis un geek qui a besoin de faire évoluer son systeme, je préfererais dépenser plus de sous en électricité et avoir une petite tutuxbox avec une Debian dessus pour en faire ce que j'ai envie de faire
).
Pareil pour le control point, le controle du MPD sur des smartphones par des applications natives n'est pas encore vraiment au point, alors que c'est le cas pour l'UPNP (corrige moi si je me trompe)
La principale différence entre l'uPNP-AV et le MPD & cie, c'est que MPD stream de l'audio, alors que UPNP-AV est comme un browser de fichiers à distance.
), le meilleur moyen de controler à distance le schmilblik est d'utiliser ton téléphone android, avec le logiciel Andromote. Dans ce même post, je n'ai pas trop compris la remarque sur l'audio. J'arrive très bien à l'écouter pour ma part !
Dans ton post sur la freebox ( merci de ton remerciement au passage
Hello,
Vu que tu connais plus la partie MPD que moi, peut-être pourrais tu répondre à une de mes problématiques.
J'ai donc un mini pc chez moi que j'utilise comme serveur, que je laisse allumé H24. Il est utilisé pour jouer de la musique sur le 5.1 qui lui est connecté, ...
Cependant, j'aimerais pouvoir faire passer toute la musique des différents postes dans la maison par ce serveur. Par exemple, que si je joue un clip sur youtube sur mon ordi portable, il envoie le son sur le 5.1 du serveur.
J'ai cherché des réponses dans la voie d'un "pilote audio à distance" mais j'ai rien trouvé de probant.
Connaitrais tu qqch qui puisse m'aider ??
Bon, je remplace mon ancien commentaire car j'ai un peu expérimenté entre temps.
Pour la andromote - je ne sais pas bien ce qui se passe avec ce truc, il découvre bien les serveurs et les renderers mais c'est impossible de pouvoir choisir autre chose que le renderer "local player". J'ai fait quelque chose de très mal pour m'assurer que cela ne venait pas de la version "free" en trouvant la version "pro" dans un coin. Et j'ai le même résultat, donc pas au point, en tout cas pas sur mon hero.
Pour la FreeBox - déjà lorsque je parlais de difficultés avec l'audio, je parlais avant tout de l'impossibilité de naviguer dans le système sans passer par une télévision (que je n'ai pas). Ensuite, j'ai eu beau trifouiller toutes les options de la freebox, je n'ai pas réussi à la découvrir un "media renderer" lui correspondant. Du coup, impossible aussi de l'utiliser pour lire de l'audio ou de la vidéo avec un controller (j'ai utilisé cidero pour cela, vu qu'andromote coince).
Sur les serveurs en général - ushare est un peu lent à l'exploration mais mediatomb marche nickel. Adopté celui-là.
Sur les renderer en général - là, sous linux, c'est pas sec du tout. Que ce soit upnprenderer pour mplayer ou gmediarenderer pour gstreamer, ça plante assez souvent. Je n'ai pas trouvé de plugin de rendu pour VLC.
Sur les contrôleurs en général - Je n'ai pu tester que cidero donc mais cela fonctionne pas mal. En revanche je me suis ainsi rendu compte d'un léger problème avec le concept. En effet, si je crée une playlist de 100 morceaux (c'est un exemple
et que je les envoie dans un rendrer. A la lecture, tout marche nickel (testé avec les deux renderers à ma disposition). Cependant le hic est que la playlist n'est pas stockée sur le renderer mais sur le controleur. Du coup, si je coupe la connexion (genre je lance ma musique, je mets mon PC en veille pour aller faire à manger 
, le renderer s'arrête logiquement à la fin du dernier morceau. Alors soit j'ai loupé une étape, soit là c'est un gros problème fonctionnel. C'est parfait pour la vidéo mais pour l'audi, je ne vois pas comment c'est jouable.
Du coup, si j'ai bien compris le concept upnp (je commence à être documenté là
, l'avantage de MPD est qu'il est totalement autonome. On lui injecte une liste, on se déconnecte et il vie sa vie. Dans le même esprit il permet la sauvegarde et la relecture de liste.
En tout cas, en attendant ton prochain commentaire, je vais arrêter mes chronophages expérimentation sur l'uPNP car en l'état je n'obtiens pas un meilleur système.
Enfin, pour répondre à ta question, la partie "streaming" n'est qu'un module de sortie (au lien d'envoyer sur ALSA, on envoie sur shoutcast). Mais la source est elle toujours le système de fichier local.
Je crois que j'ai trouvé à peu près une piste :
)
http://fluoblog.wordpress.com/2008/04/06/stream-audio-sur-un-serveur-pul...
Pulseaudio étant un serveur audio au même titre que Jack ou autre, il suffit de le sélectionner, puis de configurer un serveur pulseaudio, et il le lira à distance.
Mais vu que j'ai un environnement très hétérogène ( linux, mac, windows, smartphones,...) j'aimerais avoir une solution plus "universelle". Si tu en connais une, fais moi signe ( autre que un geste de la main vers un transmetteur audio sans fil ce qui ne m'intéresse pas
A ma connaissance tu as trois options de son à travers le réseau : esound qui est le démon d'Enlightenment, ARTS qui est celui de KDE 3 (je ne sais pas s'il a survécu au 4) et pulseaudio, tout récent.
esound est un peu vieillissant et n'était pas forcement très tolérant aux aléas réseau lors de mes tests. ARTS pourquoi pas, j'avais testé à l'époque où j'utilisais KDE et ça marchait pas si pire. Enfin pour le dernier, sur le papier, il décoiffe : vraie transparence réseau, bascules dynamiques (tu peux envoyer le son rediriger le son d'une source A vers une cible B), possibilité de régler le volume par application, etc, etc.
A l'origine j'avais étudié cette option pour les mêmes raisons que toi en me disant que je pouvais jouer le son sur un serveur, et le redispatcher sur l'ensemble de la maison. En jouer deux et créer deux ensembles de baffles, etc. Après en pratique c'est un de ces bordels... Sur mon échelle de l'emmerdement linuxien avec ALSA comme sommet et CUPS au milieu, PulseAudio obtient un bon 7/10. Entre la sécurité de paranoïaque (au cas où le voisin te tire ton audio, on sait jamais..., surtout sur ton LAN), la belle collection de bugs (genre les beeeep qui se se transforment en Pffouit...) et enfin l'absence de compression, j'ai lâché l'affaire, déclaré forfait... Le dernier point était assez bloquant car à quoi me servait de monter une réseau audio aussi complexe si au final j'occupais plus de bande passant qu'en véhiculant du FLAC... Ceci dit le plugin de compression était prévu à l'époque, c'était il y a un an et les choses ont peut-être bien changé. En effet, si je m'en réfère au tuto que tu cites, le gars semble dire que le débit est différent en fonction du format utilisé (je ne comprend pas bien pourquoi ceci dit, vu comment le système est gaulé).
En version web, il y a aussi NeoMPC qui est très adapté aux téléphones mobiles: http://code.google.com/p/neompc/ (perso je l'utilise d'une façon dérivée, car son interface mini permet de l'intégrer à d'autres projets).
Et surtout en version application native pour iPhones, il existe iMPDclient: http://code.google.com/p/impdclient/
@tof très intéressant ça ! Pour installer impdclient, il faut jailbreaker l'iphone j'imagine ? Sinon, tu as des copies d'écran de noeompc pour voir un peu à quoi cela peut ressembler ?
en plus meme en jailbreak il n'est pas encore dispo pour la V2.0 du firmware..
Voici les captures d'écran de Neompc
Controle: http://www.galipe.net/wp-content/uploads/neompc-control.png
Playlist: http://www.galipe.net/wp-content/uploads/neompc-playlist.png
Navigation: http://www.galipe.net/wp-content/uploads/neompc-browse1.png
Navigation: http://www.galipe.net/wp-content/uploads/neompc-browse2.png
Le script utilise une méthode de template du style Smarties + CSS, donc l'interface est modifiable à souhait. Ici j'utilise la template standard en 240 pixels de large.
Les inconvénients principaux sont:
- pas d'avance et retour rapide
- pas de fonction recherche (mais c'est dispensable pour une utilisation sur mobile)
- la fonction affichage du morceaux en cours et du temps n'est pas "accurate", j'entends par là que lors du chargement d'un morceau, il en récupère les infos du morceau et du temps et le script calcule et affiche de façon autonome le temps restant, si quelqu'un entre-temps avec un autre client sur le même serveur MPD fait une avance rapide sur le morceaux, ou change le morceau, les infos de lecture ne sont pas mises à jour en direct.
C'est pour éviter que le script fasse des appels incessants au serveur MPD. En utilisation mono-client pas de problème, en utilisant multi-clients c'est plus dérangeant...
L'avantage principal est que ce script est hyper simple à utiliser et qu'on peut l'adapter, si par exemple quelqu'un s'y connais un peu en php/html/javascript il peut se faire une template "à la iphone" comme cette appli web pour nabaztag sur iphone: http://www.nabzfood.com/iphone/index.php
@Tof merci pour ces info, va falloir que je teste tout cela
Une "petite" mis à jour du post d'origine
Merci pour cet article ça donne des idées
Alleluia!!!Mon souhait est exhaussé Comme Sooske merci pour cet article et comme d'habitude j'imprime et je digère.
MPD n'est absolument pas sexy et n'impressionnera jamais vos amis.
Pas d'accord ! MPD est justement le service qui a le plus impressioné les gens qui ont pu voir mes Pcs en fonctionnement, du genre
ah bon, tu peux continuer d'écouter ta musique même avec le PC éteint ?
Si la notion de serveur ne parle à personne car la plupart des gens n'en voient pas d'usage pratique, le fait de pouvoir écouter ses MP3s en lançant la musique sur la chaîne hi-fi depuis son lit est qqch compris directement..
Maintenant que tu as commencé à mettre le son en réseau, il te reste encore à mettre en place un serveur pulseaudio pour compléter ta configuration ( là encore il y a de quoi s'amuser
)
@Chimrod Je dis cela un peu ironiquement : D'un côté y'a le bureau qui fait des toupies, ne sert à rien, mais qui impressionne les amis, et de l'autre MPD
PulseAudio j'avais mis cela en place un moment mais c'est vite tombé court. L'idée de pouvoir envoyer du son à distance sur une machine pouvait servir 1/ à mon PC/Linux qui n'a pas ses propres baffles 2/ A des "itinérants" pour injecter de l'audio de manière ponctuelle.
Le cas 1/ je l'ai vite réduit à néant en ayant la brillante (ironique) idée de coller un câble audio pour combler les 20 cm entre les deux machines, et le cas 2/ c'est réduit à néant tout seul car réduit aux seuls itinérants non-windowsien et suffisamment courageux pour se frapper le paramétrage. Du coup je suis tombé un peu à court d'usage, mis à part cela ça marche très bien.
Bonjour !
J'aimerais savoir s'il est possible de réaliser un tel serveur pour la vidéo ? J'imagine que cela doit être possible mais je ne sais pas trop quel logiciel utiliser. Mplayer ne semble pas pouvoir être contrôlé à distance, si ? Est-il possible de contrôler VLC à distance simplement ?
Merci d'avance pour vos éclaircissements !
@Geek87 Oui c'est parfaitement possible avec VLC en tant que client et VLC en tant que serveur VOD (Vidéo On Demand). Pour plus d'information là dessus, cherche VLC+VOD sur google, j'avais trouvé pas mal de tutos (en anglais) à l'époque où je pensais la solution intéressante pour moi.
Salut !
Je cherche à transformer une vieille machine en serveur MPD: c'est un client léger qui possède un processeur d'environ 300Mhz, et 128 Mo de RAM. Coté "disque", je pense à une carte FLASH de 512Mo.
Par contre, je n'ai pas encore trouvé la distribution linux qui me conviendrait (boot rapide, légere, etc...)
Est ce que quelqu'un aurait une idée pour m'aiguiller ?
Merci
@Ludovic certains vont sûrement te conseiller des distributions ultra taillées mais moi sur une machine comme cela (PIII 300Mhz), je collais une mandriva de base et je virais les services qui ne servait à rien (avahi, netfs, etc), n'installait aucun paquet touchant de prés ou de loin au graphique (X11 & co). Au final ça démarre aussi vite qu'une distrb taillée et tu as tous les paquets et les mises à jour sans contreparties visibles. My 2 cents opinion
Ok, pourquoi pas une mandriva, MAIS...
Il me semble que mandriva n'est dispo qu'en version i586 ou x86_64, or mon processeur ne doit pas être compatible 586, enfin je ne suis pas sur ...
Je vais tester
@Ludovic Pour que ton processeur ne soit pas compatible i586, il faudrait que ce soit un 486 ou moins... Là pour le coup ce serait vraiment un ancêtre...
Je ne vois pas le format wma dans la liste ? Est-il supporté ?
Merci pour cet article.
En passant par le module Jack ça doit être jouable mais il n'y a rien de natif il me semble. Sauf peut-être dans la version "non-libre" dont je parle dans l'article.
Je vais tester tout ca ce soir
Merci
Salut,
Merci pour cette mine d'information.
J'ai vu que tu avais réussi à rendre une freebox passive pour la vidéo. Elle n'etait là que pour recevoir les flux vidéo envoyés par les PC: trés interessant.
Peut on faire la même chose pour le son ?
vlc permet de convertir le format venant de pas mal de source. Je voudrais qu'il recoive je son joué localement avec un rhytmbox ou un banshee. Mais je ne trouve pas comment lui dire d'écouter tout ce qui est envoyé à alsa ou pulseaudio ...
As tu déjà creusé cette question ?
Merci pour tes lumières !
Miz
@Miz As tu lu le dernier chapitre FreeBoxHD/MPD, ça me semble plutôt bien convenir à ton besoin. Personnellement c'est une méthode que j'ai abandonnée avant tout pour une question de qualité audio. En effet ce n'est pas la peine que j'encode mes CD en FLAC pour derrière transcoder le flux en MPEG2
Oui, c'est dans ce chapitre que j'ai pu voir que vlc pouvait accepter des flux venant de stdin !
MPD envoie à une fifo. sax lit cette fifo, converti et envoi via stdin à VLC.
Mais je ne suis pas sur que Rythmbox puisse ecrire dans une fifo ... (à creuser !)
C'est pour cela que j'avais pensé me greffer plus bas et dire à VLC de lire tout ce qui sort au niveau du son (ALSA ?)
En ce qui concerne la qualité audio, je suis d'accord avec toi. A l'époque, j'avais tout compréssé en MP3 ...
Problème avec ce tuto, les deux lignes ci-dessous dans le fichier de configuration /etc/mpd.conf ne peuvent être identiques :
playlist_directory "/musique/mdp"
db_file "/musique/mdp" -----> transformer en /musique/mdp/db_file
A moins que je sois passé à coté d'un truc...
Non, c'est toi qui a raison
C'est corrigé.
Au risque de me faire trucider, j'ai du mal à comprendre ce que MPD apporte par rapport à des solutions de type UPNP-AV dans le cadre d'un réseau personnel ... Vu qu'on peut également avoir des serveurs ( genre un NAS) , des lecteurs ( genre la freebox sans mod particulier), des points de controle ( genre un téléphone Android ) qui permet de router différents morceaux vers différents points de sortie, permettant ainsi de faire du multiroom dans tous les sens ...
De plus il existe des foulitudes de lecteurs compatibles nativement ...
La seule application utile que je vois à MPD est sa compatibilité avec un flux de type shoutcast permettant de controler aisément à distance de partout dans le monde une webradio, voire plusieurs webradios ...
Donc merci d'éclairer ma lanterne
Pour te faire comprendre l'intérêt que j'y vois (ce qui n'est pas forcement le cas de tous), je vais passer par la topologie actuelle de mon réseau. Déjà je n'ai pas de télévision, donc la freebox HD va très bientôt partir caller les livres dans la bibliothéque. J'ai donc sur ce réseau, dans le salon, le modem ADSL (freebox) et un portable ancienne génération qui sert de poste banalisé (bien pratique pour les recettes de cuisine ou checker ses mails le matin avec la tartine
, mais aussi de lecteur audio (MPD), vidéo (DVD/AVI) sur un rétroprojecteur.
Dans mon bureau j'ai une grosse machine qui est allumée 24/24 pour divers raison sur laquelle est virtualisée un serveur linux, avec le mail, le web (intranets), MPD à nouveau, DHCP, DNS, NAS (WebDAV, SMB, NFS), etc.
Enfin dans les chambres, j'ai un troisième serveur basse consommation (mini ITX) qui contient encore un serveur MPD, réalise les backups du réseau, et très bientôt va être équipé pour sérvir de baby-vidéo-phone.
Comme tu le vois, MPD pour moi est une brique logicielle que je colle sur un nombre restreint de machine. J'obtiens ainsi un nombre d'apareil bien moins important que si j'avais un NAS dans un coin, un serveur pour le mail, des nodes AV dans 4 pièces, etc...
Oki. C'est assez intéressant comme utilisation. Je pensais que tu justifiais l'utilisation du MPD en ayant pas de point de terminaison PC mais des points de terminaison "chaines Hifi" directement connectées à ton serveur par les deux sorties audio gérées simultanément dont tu parles.
Je ne veux pas insister, mais, tu peux très bien avoir un ordi que tu utilises comme NAS, serveur mail, backup, ... ET serveur UPNPAV, et comme clients, des postes banalisés .
Néanmoins, ton article a été d'une grande aide car il m'a permis de voir l'usage principal que je pourrais en faire, utiliser sa modularité importante couplée à son administration à distance pour gérer facilement une webradio !
Mais vas-y, insiste, ce ne serait pas la première fois sur ce site qu'un contributeur plus éclairé que moi me fais changer d'avis
Dans mon cas, chaque machine cliente dispose d'un montage NFS avec le Serveur. Les services MPD installés dessus pompent sur ce partage pour l'audio principalement, la vidéo dans une moindre mesure, mais aussi pour un tas d'autres choses (accès à nos documents de n'importe où).
Si j'ajoute un service genre "mediatomb" sur le serveur, il me faut des softs client pour la lecture qui soient compatible UPNPAV (je ne suis pas certain que ce soit le cas avec MPD). Donc mise à par rajouter de la complexité, qu'est-ce que fonctionnellement j'y gagne ? Au fond, MPD est surtout, dans mon cas, un service de lecture audio très facile à commander à distance, à synchroniser, etc. Nous utilisons nos téléphones pour commander l'ambiance musicale de chaque pièces à partir d'une simple interface WEB qui marche très bien (malheureusement, les clients MPD pour smartphone Android ne gèrent pas encore le multiserveur).
Tu trouveras ici : http://en.wikipedia.org/wiki/UPnP_AV_MediaServers
tous les clients et serveurs disponibles pour UPNP-AV.
Je pense que tu n'y perds pas par rapport à http://en.wikipedia.org/wiki/MPD_%28Music_Player%29 vu que pour MPD si j'ai tout compris il te faut tout de même un lecteur compatible, au moins avec un stream shoutcast ...
Pour moi, l'avantage de UPNP AV sur MPD, c'est la plus grande adoption par le marché. C'est tout à fait une autre philosophie ( au lieu d'être un serveur audio, c'est plus un explorateur de fichiers à distance), mais ca reprend à peu près tous les avantages que tu cites de MPD ( controle à distance, architecture client-serveur, ...)
MPD après y gagne de par sa plus grande modularité, tu peux lui mettre plein d'extension de sorties au cu ...
L'argumentation tient la route mais à l'évidence ce n'est pas pour tout de suite l'upnp sur MPD :
http://musicpd.org/mantis/view.php?id=1670
Bon, j'ai testé le mode upnp sur la freebox est cela remplace très avantageusement l'ancien système "ftp" que j'utilisais. Merci pour ça !!
Mais maintenant que je connais mieux le concept, je reste un peu circonspect car, mis à part pour des ControlPoints de type "boi-boîtes" (ce qui est le cas de la freebox), cela n'apporte pas grand chose (mais j'ai peut-être loupé un truc) par rapport à un simple montage de base (CIFS ou NFS) sur les machines clientes. Montage qui est un peu plus efficace pour le multimedia car les fichiers sont "seekables" de manière fluide.
En attendant que je réussisse à faire tourner la sortie VGA la carte vidéo du portable qui nous sert de lecteur multimedia, cela me permet d'utiliser la freebox pour lire les vidéos, mais lorsque j'y serais arrivé (si j'y arrive un jour
, là je serais un peu en panne d'usage...
En fait, arrête moi si je me trompe, l'uPNP me semble surtout parfait pour des particuliers qui veulent monter leur réseau domestique sans connaissances en informatique/administration en enquillant simplement sur leur LAN des boîtes spécialisées (NAS/DCP, ControlPoints audio et vidéo, etc.).
Poster un nouveau commentaire