Hi, I was recently trying to to tune my pulse audio setup, when I have run into some problems. So far I have used pulse in a pretty centralized fashion. I have one server on a standalone machine and 3-4 client machines that access the server directly using esound or native protocols. Also some audio applications on the server access pulse daemon with native protocol using unix sockets. I would like to switch it into more distributed setup. I would like to be able to switch target of a stream playing on my notebook between remote pulseaudio output or local alsa (for example I want the audio go to local loudspeakers when I leave the room). As far as I understand I need a local pulseaudio server for that, which will have two sinks: one using local alsa, and one using some kind of networked sound. I had read the FAQ and got the clue that I should use rtp: load-module module-null-sink sink_name=rtp load-module module-rtp-send source=rtp.monitor set-default-sink rtp I did this and load-module module-rtp-recv on the other server side. However this seems to generate much more network traffic than when I was accessing the remote pulse audio server directly. At least I can see that my wireless driver produces a lot of errors and communication basically stalls, when I use rtp. I suspect that this is a hardware/driver/bandwidth problem, as it works ok on the cable connection in the same setup. [I am on Linux, with an old Wi-Fi 11mb router/nic using ipw2100 driver] This is not very nice, as forces em out of using wireless, which by definition means that moving is harder. Now not only streams have to be moved but also wires :) My first question: is using rtp the only way to make a "remote sink" on a local pulseaudio server, so that I can switch sinks between local and remote using pavucontrol? What protocol is used when the library connects to the remote server? Is is also rtp? My second question is unrelated to rtp. I have problems with local mixing on the server. I use a local mpd to play music on that server and it works well. However when I simultanously try to play some audio from a remote mplayer using esound protocol (or an rtp stream coming from my notebook, for that matter) I get only slow garbage from the speakers, and often pulseaudio dies after that. It is not actually killed, but is unable to play again, even if I stop all the stream and just send one of them again). Do I have to do anything special to achieve mixing on the server side? Or is it solely caused by low performance of my server? I know that It is particularly annoying that the server is not usable after such mistake. This happens for example when I listen to an internet radio and then enter a website with a video on it, that is configured to produce sound via pulse server. It is easy to inconciously cause my setup hang in this way, and after that there is no easy way to reset it---I need to ssh to this headless machine and restart the server. Not an option for anybody else in house... Any hints are welcome Andrzej
