Start the server on both sides and presto.sort of. The sink refers to the sink name on the pi side, which then also needs a name add a corresponding sink_name to the module-alsa-sink line in default.pa there: load-module module-alsa-sink device=hw:0,0 sink_name=bcm1 If you don't put a sink_name in, pulseaudio won't start. To do this, comment out the "default-server" in /etc/nf and add a local /etc/default.pa containing: load-module module-tunnel-sink sink_name=rpi_tunnel server=tcp:192.168.2.13:4713 sink=bcm1 In this case, you have a server running on both sides and one hands off to the other. This is the other way mentioned in the pulseaudio docs. The way around this is to use the "tunnel" method. This is a harder issue to resolve, because it looks for a local pulseaudio server, and as described, using a direct connection means no server can be run locally. KDE's desktop bells and whistles also did not work. If you've been using pulseaudio before (I was not), you may have them installed already. Other distros should have similiar packages. For flash stuff in the browser (eg, youtude) you need alsa-plugins-pulseaudio (these are what actually connect to the remote server). For that, on fedora, you need the mpg123-plugins-pulseaudio package. Unfortunately, none of the various sound applications from my PC worked right away mpg123 would not run at all. There is, unfortunately, a noticeable lag in the sound if you are watching video. :) It and my desktop are on a wired LAN pulse streams raw pcm data (I believe), so bandwidth usage corresponds to the sample rate of the source, 1 kB/s and up. While playing sound streamed from the network, pulseaudio on the pi uses about 10% of the CPU and a trivial amount of memory. Now you can start pulseaudio and it will renice itself -11, which is probably a higher priority than most of the other processes (look at the NICE value in top). You have to actually run a log in before these changes take place if you use ssh with the pi, just use login. For that, add to /etc/security/nf: hard nice soft nice -20 Add (e.g.) user pi to that group: usermod -aG pulse-rt piīut on raspbian, you still won't be able to renice as pi. There is no pulse-rt group created when pulseaudio is installed on raspbian, so then: groupadd pulse-rt So (as root, or sudo): chmod u+s /usr/bin/pulseaudio You can do this manually with nice, but pulseaudio will do it automatically for root, or members of the pulse-rt group, if the executable is "setuid", meaning it can make use of some root privilleges and then change down to the correct unprivelleged uid ( ping and passwd also need to do this). However, as mentioned in man pulseaudio, it is also a good idea to "renice" the process to give it a higher priority. Since this is a network app, it's not a good idea to run it as root. Load-module module-alsa-sink device=hw:0,0 etc/pulse/default.pa # See man default.pa Beware this is seconds and the default is 20 (meaning it will keep "mysteriously" dying if you don't set this). You can use -1 for exit-idle-time to keep the daemon running indefinitely. Hence, on the pi side, you should explicitly start and stop the pulseaudio server process, configured thusly: Fedora does not even include a systemd boot service entry for it. So, that one line "nf" is actually all you need on the desktop/client side, if all you are going to do is use the network (but see "Yet More Complications", below).Īlthough the pulseaudio daemon (on the receiving/server side) can be run as a system service, the developers of pulse recommend against it, and in fact on the pi the init script just causes a warning to be issued: you still have to start it yourself. Using lsof -i -P it appears that lower level plugins for various media players do the work. However, as it turns out, you don't have to run it at all on the desktop (sending) side, something which is not spelled out in the pulseaudio docs. It will run in the foreground (probably because it then doesn't read nf?). N: main.c: User-configured server at tcp:192.168.2.13:4713, refusing to start/autospawn. But here's something that then had me confused for a while - with a server specified, pulseaudio would not even start: > pulseaudio -start My pi's LAN address with the default pulseaudio port. I've minimized the /etc/pulse config files on both sides. I now have a (fedora 17) desktop streaming sound to the pi. The official instructions for creating a "direct connection" on a network hopefully just work for most people, but it seems pulseaudio and I do not get along that well: it took me hours.
0 Comments
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |