[pulseaudio-discuss] How to PA -> PA

Colin Guthrie gmane at colin.guthr.ie
Wed Jun 18 01:59:50 PDT 2008


First of all, I'm a bit confused by your setup.

Am I right in saying that you want to *run* applications on you your 
server but have the display *and* sound come out on the X client? This 
is what I'd guess as being the typical setup and should work out of the 
box without any manual tweaking:

On the Old X Client Box, you have a local (per-user) pulseaudio deamon 
running and module-x11-publish loaded (the default).

You SSH (with X11 forwarding) to the application server and run the X 
app of choice. On this server you have the pulseaudio client library (no 
need for an actual daemon). When the App in question tries to output 
sound, it should go through the pulse client libraries (possibly via an 
ALSA plugin), notice the pulse configuration that has been forwarded 
with the X11 tunnel, and automatically push the sound to your X Client 
box's PA daemon for local output. Is this the scenario you want ot 
achieve? If so, it should "just work"(tm) out of the box without too 
much tweaking.

Fog_Watch wrote:
> On the client, with the sound card and speakers I can mpg123 -o
> alsa /tmp/filename.mp3 and get sound. But, if I /etc/init.d/pulseaudio
> start, which starts pulseaudio as:
> /usr/bin/pulseaudio --log-target=syslog --disallow-module-loading=1
> --fail=1 --daemonize=1 --system
> I get silence.  Silence is not golden.  Is there some documentation or
> something obvious, that I missed?

Assuming my above explanation is wrong, and that what you want is to see 
the visual display on the X client box, but have the sound come out the 
application server (that's what you client.conf says), then you could be 
running into a bug here.

 From what I can tell pulse daemon is running on the server and when it 
is not running on the client, the sound comes out, correctly, fromt he 
server? Is that correct?

If so, the problem (chicken/egg scenario) is that the pulseaudio client 
library gets it's config parameters from multiple sources with varying 
degrees of priority. [In 0.9.10] these are as follows:

1) client.conf
2) X11 Properties of the root window
3) Environment variables

I've changed this behaviour in the git master (gotta get used to that as 
opposed to "svn trunk" ;)) to change the order of 1 and 2 around.

So what I think is happening here is that before you start pulse server 
on your "client", your x11 root window has no properties so it will get 
it's config from the client.conf and it's all good. But after you start 
the pulse daemon, it adds some x11 props for the *local system*, the x11 
props have precedence over your client.conf and it stops working (or 
rather the sound comes out via the local pulseaudio daemon and you 
presumably don't have any speakers plugged in!).

I'm not really sure this is correct, but this is my guess so far! It's 
odd that you are starting a system deamon (why not per user?) or is this 
a dumb machine which only has a root account?

If you can describe your end goal a little clearer I can probably give 
you more accurate advice.


More information about the pulseaudio-discuss mailing list