Les instructions officielles pour la création d' un « lien direct » sur un réseau , espérons que de travail pour la plupart des gens, mais il semble PulseAudio et je ne suis pas le long de ce bien: il m'a fallu heures . [Outre la "connexion directe", vous pouvez également utiliser une méthode "tunnel" décrite plus bas, mais je vous recommande de la lire d'abord.]
J'ai maintenant un son de streaming (fedora 17) sur le pi. J'ai minimisé les /etc/pulsefichiers de configuration des deux côtés. Côté bureau:
/etc/pulse/client.conf
# See man pulse-client.conf
default-server = tcp:192.168.2.13:4713
L'adresse LAN de mon pi avec le port pulseaudio par défaut. Mais voici quelque chose qui m'a ensuite confus pendant un certain temps - avec un serveur spécifié, pulseaudio ne démarre même pas:
> pulseaudio --start
N: [pulseaudio] main.c: User-configured server at tcp:192.168.2.13:4713, refusing to start/autospawn.
Il s'exécutera au premier plan (probablement parce qu'il ne lit alors pas pulse-client.conf?). Cependant , il s'avère que vous n'avez pas du tout à l'exécuter du côté bureau (envoi) , ce qui n'est pas précisé dans les documents pulseaudio. En utilisantlsof -i -P il semble que des plugins de niveau inférieur pour divers lecteurs multimédias font le travail.
Donc, cette ligne "client.conf" est en fait tout ce dont vous avez besoin du côté bureau / client, si tout ce que vous allez faire est d'utiliser le réseau (mais voir "Encore plus de complications", ci-dessous).
Bien que le démon pulseaudio (côté réception / serveur) puisse être exécuté en tant que service système, les développeurs de pulse le déconseillent , et en fait sur le pi, le script init ne fait qu'émettre un avertissement: vous devez encore démarrer vous-même. Fedora n'inclut même pas d'entrée de service de démarrage systemd pour cela.
Par conséquent, du côté pi, vous devez explicitement démarrer et arrêter le processus du serveur pulseaudio, configuré de la manière suivante:
/etc/pulse/daemon.conf
# See man pulse-daemon.conf
log-level = info
exit-idle-time = 10800 # 3 hours
Vous pouvez utiliser -1 pour exit-idle-timecontinuer à exécuter le démon indéfiniment. Attention, ce n'est que quelques secondes et la valeur par défaut est 20 (ce qui signifie qu'il continuera à mourir "mystérieusement" si vous ne le définissez pas).
/etc/pulse/default.pa
# See man default.pa
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.2.0/24
load-module module-alsa-sink device=hw:0,0
Comme il s'agit d'une application réseau, ce n'est pas une bonne idée de l'exécuter en tant que root. Cependant, comme mentionné dans man pulseaudio, c'est aussi une bonne idée de "renice" le processus pour lui donner une priorité plus élevée. Vous pouvez le faire manuellement avec nice, mais pulseaudio le fera automatiquement pour root, ou les membres du pulse-rtgroupe, si l'exécutable est "setuid", ce qui signifie qu'il peut utiliser certains privilèges root, puis passer à l'uid sans privilèges correct ( pinget passwddoivent également le faire). Donc (en tant que root ou sudo):
chmod u+s /usr/bin/pulseaudio
Aucun pulse-rtgroupe n'est créé lorsque pulseaudio est installé sur raspbian, alors:
groupadd pulse-rt
Cela vous donnera un gid comme 1003. Ajoutez (par exemple) l'utilisateur pi à ce groupe:
usermod -aG pulse-rt pi
Mais sur raspbian, vous ne pourrez toujours pas renice en tant que pi. Pour cela, ajoutez à /etc/security/limits.conf:
@pulse-rt hard nice -20
@pulse-rt soft nice -20
Vous devez réellement exécuter une connexion avant que ces modifications ne se produisent; si vous utilisez ssh avec le pi, utilisez simplement login. Vous pouvez maintenant démarrer pulseaudio et il se renice -11, ce qui est probablement une priorité plus élevée que la plupart des autres processus (regardez la valeur NICE danstop ).
Lors de la lecture du son diffusé depuis le réseau, pulseaudio sur le pi utilise environ 10% du processeur et une quantité de mémoire insignifiante. :) Elle et mon bureau sont sur un LAN câblé; l'impulsion transmet des données pcm brutes (je crois), donc l'utilisation de la bande passante correspond au taux d'échantillonnage de la source, 1 kB / s et plus. Il y a, malheureusement, un décalage notable dans le son si vous regardez la vidéo.
Encore plus de complications ...
Malheureusement, aucune des différentes applications sonores de mon PC n'a fonctionné immédiatement; mpg123ne fonctionnerait pas du tout. Pour cela, sur fedora, vous avez besoin du mpg123-plugins-pulseaudiopackage. Pour les éléments flash dans le navigateur (par exemple, youtude) dont vous avez besoin alsa-plugins-pulseaudio(ce sont ceux qui se connectent réellement au serveur distant). Les autres distributions devraient avoir des packages similaires. Si vous utilisiez pulseaudio auparavant (ce n'était pas le cas), vous les avez peut-être déjà installés.
Les cloches et sifflets de bureau de KDE ne fonctionnaient pas non plus. Il s'agit d'un problème plus difficile à résoudre, car il recherche un serveur pulseaudio local et, comme décrit, l'utilisation d'une connexion directe signifie qu'aucun serveur ne peut être exécuté localement. La solution consiste à utiliser la méthode "tunnel".
module-tunnel-évier
C'est l'autre façon mentionnée dans les documents pulseaudio. Dans ce cas, vous avez un serveur qui s'exécute des deux côtés et une main sur l'autre. Pour ce faire, commentez le "serveur par défaut" /etc/client.confet ajoutez un local /etc/default.pacontenant:
load-module module-tunnel-sink sink_name=rpi_tunnel server=tcp:192.168.2.13:4713 sink=bcm1
Si vous n'y insérez pas sink_name, pulseaudio ne démarre pas. Le sinkfait référence au nom de l'évier du côté pi, qui a alors également besoin d'un nom; ajoutez-y un correspondant sink_nameà la module-alsa-sinkligne default.pa:
load-module module-alsa-sink device=hw:0,0 sink_name=bcm1
Démarrez le serveur des deux côtés et hop ... en quelque sorte. Alors que tout, y compris les bips KDE, était désormais effectué, la lecture flash du navigateur bégayait mal. Cependant, dans un autre environnement de bureau (en fait, juste un gestionnaire de fenêtres, fvwm), tout allait bien.
J'aime KDE mais je peux vivre sans bips, donc pour l'instant je vais m'en tenir à une connexion directe.
Dépannage
Si vous rencontrez des problèmes, l'utilisation pulseaudio -vvvv --log-level=debugde pi fournit de nombreux messages de débogage. Initialement, lorsque je n'ai pas pu obtenir de son sur le pi, cela a signalé un problème "lié à un bug dans le pilote ALSA bcm2835" qui m'a semblé étrange car le son était correct avec juste alsa, et je suis sûr qu'il existe un logiciel pi autour qui dépend sur pulseaudio - apt-get remove pulseaudioet une réinstallation apt-get install pulseaudiosemblait résoudre ce problème ... Pas une solution que j'aime voir, mais bon, au moins maintenant je peux écouter du tish sans avoir à brancher des haut-parleurs dans chaque boîte. La plupart.