[pulseaudio-discuss] How to PA -> PA
Colin Guthrie
gmane at colin.guthr.ie
Wed Jun 18 01:59:50 PDT 2008
Hi,
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.
Col
More information about the pulseaudio-discuss
mailing list