[pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk

[Tanu Kaskinen]

On Sun, 2010-05-16 at 22:41 +0100, Nix wrote:
> On 16 May 2010, Tanu Kaskinen spake thusly:
> > "User-configured" means that there's a server address configured either
> > by setting the PULSE_SERVER environment variable, by setting the
> > PULSE_SERVER X11 root window property, or by setting the default-server
> > option in client.conf. The logic is that if one of those is set, then
> > the server that the user wants to use is probably running on some other
> > machine, or even if the configuration points to the local machine, the
> > server is already running.
> 
> Wrong logic :/ I set PULSE_SERVER via machine-invariant shell script run
> only by session leaders (as these either logged in directly, or sshed
> in, thus lost their environment variables), to refer to, roughly, the
> machine on which the X DISPLAY is running. (I can't use the X cookie
> consistently because some of these sessions have no access to X but I
> *do* want them to be able to generate sounds: more generally, if I do
> generate a session with no access to X, I don't want to cut it off from
> sound generation too: the two should be orthogonal.)

So you have a server with display and keyboard and all that stuff, and
there are basically three ways that the server is used:

1) Not as a server, but as a regular desktop machine, i.e. local X11
session.

2) Remotely through ssh, running an X11 session.

3) Remotely through ssh, not running an X11 session.

Pulseaudio handles cases 1 and 2 without any extra configuration, but
not case 3. So do you really have a client machine that has a sound card
but no graphical display, or if it has a graphical display, it's still
used to ssh to the server outside any X11 session and run programs that
generate sound and the sound needs to be sent to the client's sound
card?

Quoting ssh's manual page:

        "Additionally, ssh reads ~/.ssh/environment, and adds lines of
        the format “VARNAME=value” to the environment if the file exists
        and users are allowed to change their environment.  For more
        information, see the PermitUserEnvironment option in
        sshd_config(5)."

Is dropping the PULSE_SERVER configuration at the server end, and
setting PULSE_SERVER in ~/.ssh/environment at the client end a
satisfactory solution?

> So PULSE_SERVER is set *everywhere* for me: in particular it is already
> set when X starts up, to the machine on which X is being started. This
> is the same sort of thing as one uses for a lot of other persistent or
> semi-persistent servers. This is how ESPEAKER worked for esd. It's how
> PGHOST works for PostgreSQL. It's how they *all* work. Can you imagine
> what it would be like if HTTP_PROXY only worked if the proxy was on
> a remote machine?

AFAIK Postgresql and HTTP proxies aren't designed to be started as part
of a login session, so they don't have the same problem as Pulseaudio.

> Pure consistency should dictate that PULSE_SERVER should affect only and
> precisely where clients should look for the PA server, not whether
> PulseAudio can start. (This was so unexpected that I didn't even figure
> it out after reading the code!)
> 
> > Since the assumptions that the code is based break on your
> > configuration,
> 
> And everyone's configuration I'd imagine. PULSE_SERVER seems like a
> likely thing to set in e.g. /etc/environment or session-wide startup
> scripts; does that mean you don't want to start a server at all? No,
> it just means you want network-transparent audio to work once you
> *do* start a server.

If you set PULSE_SERVER in /etc/environment, that's going to be a static
value because /etc/environment is not a script. If the value is static,
that means that it can't point to per-user pulseaudio instances, and
since --start is used only when starting per-user instances, there's no
problem.

Why would you set PULSE_SERVER to point to the local yet-to-be-started
per-user instance in a session start-up script? Other than in the setup
that you currently have, that is. To me your requirements seem very
rare. I don't mean that we don't need to care about your requirements,
just that breaking "everyone's configuration" doesn't seem likely.

> >               apparently some documentation is needed somewhere in
> > order to prevent the users from shooting themselves in the foot
> 
> I don't understand why you're banning this at all.

Ok, I'll tell the story why I wrote this patch. I was working on the
server discovery logic for D-Bus clients, and that logic will be very
similar to the discovery logic for the native protocol clients. So, I
was reading the native protocol's client code for inspiration, and
noticed that the X11 properties override the configuration in
client.conf. That seemed strange, because the X11 properties are set
automatically, and the user probably usually doesn't know anything about
the existence of the X11 properties. That means that if an user sets an
address for a remote server in client.conf, that won't have any effect
if start-pulseaudio-x11 is used (and it is used in most cases), and the
user won't have any idea why it's not working.

The reason why the X11 properties override client.conf is apparently
just that the X11 properties are similar to environment variables, and
environment variables of course override configuration files. I'm still
not sure if X11 properties really are like environment variables, but I
was pointed to a different solution than reordering the configuration
source priorities: make start-pulseaudio-x11 not start a local per-user
instance if the user has a server address in client.conf (or other
configuration sources).

That solution seemed to work fine: the address in client.conf most
likely doesn't point to a local per-user daemon, and this solution also
avoids starting a redundant pulseaudio instance that won't be used
anyway. The X11 properties won't override client.conf anymore, because
if start-pulseaudio-x11 doesn't start a local daemon anymore, the X11
properties won't be set at all.

There's still one problem, though: when editing client.conf within an
X11 session, the X11 properties are still set, so the client.conf
changes will take effect only after logging out and logging back in, or
after shutting down pulseaudio in some other graceful way.

Oh, and there's that other problem too, which Colin mentioned yesterday:
autospawning after a crash doesn't work until the X11 properties are
cleared (needs confirmation, but I'm fairly sure that the props aren't
cleared automatically).

For the record, below are the IRC logs that I managed to dig up. I
wouldn't have remembered the patch background otherwise :)


2010-01-06:

16:41 < tanuk> mezcalero, coling: Is the server discovery via X11
properties used in any other situation than in the remote X use case?
16:42 < coling> tanuk, well technically it is used for local X use case
by default too as it is loaded by start-pulseaudio-x11
16:43 < coling> but it is of course not *needed* for that, it's just a
byproduct
16:43 < coling> but AFAIK that's the only use case.
16:43 < coling> (although padevchooser used it too, but it's deprecated
as you know)
16:44 < tanuk> I plan to publish the TCP D-Bus server address only in
the X11 prop, so it would be used only for remote server discovery. I
was worried whether it's needed in local use cases too - good to hear
that it probably isn't.
16:49 < coling> tanuk, yeah I certainly don't think it's needed, but
like I say it is technically *used* locally too.
16:50 < coling> tanuk, but the way it works is that the PULSE_SERVER
prop actually contains multiple addresses... a local socket, a tcp6
address, a tcp4 address etc.
16:50 < coling> tanuk, and the client uses them in order.
16:50 < coling> first one that works wins
16:50 < coling> So that local seesions tend to go via local socket, but
remote ones try that, fail and fall back to a networking version
16:50 < coling> tanuk, I'm guessing you could adopt the same approach?
16:53 < tanuk> coling: It's a bit messy, so for simplicity I wanted to
put only one address there. But now that you mentioned ipv6, that won't
do.
16:59 < coling> And we'll be running out of ipv4 in 4 years if the
scaremongers are to be believed!
17:15 < tanuk> Oh, this is something I hadn't noticed earlier: the X11
prop overrides the default_server option in client.conf. That seems
strange, but whatever...
17:26 < coling> tanuk, are you sure?
17:28 < tanuk> coling: Yes, pa_client_conf_from_x11() is called after
pa_client_conf_load() in pa_context_new_with_proplist(), and _from_x11()
overwrites conf->default_server always if PULSE_SERVER is found.
17:29 < coling> tanuk, actually yes you are right, but if you recall the
horror of #606 it should be mitigated at startup/x11 login time
17:29 < pulsator> coling: Ticket #606:
http://www.pulseaudio.org/ticket/606 Owner: lennart; Status: new;
Component: daemon and Summary: [PATCH] pulseaudio systemwide is a pain
17:30 < coling> i.e. the idea is that if a default server is specified
in client.conf, then the daemon wont be started and the x11 modules wont
load and the x11 prop wont be set.
17:30 < coling> Not sure of the current status tho'.
17:30 < coling> (i'm almost too scared to comment on the bug again!)
17:32 < tanuk> coling: I see. I guess it still works. It's incompatible
with the system-wide mode, but that probably doesn't matter.
17:32  * tanuk has to read the bug
17:33 < coling> tanuk, get a cup of tea and prepare for a long read :p
17:33 < coling> tanuk, to be honest the comments on the bug are mostly
irrelevant - me trying in vein to explain how something works and the
other guy just not getting it and becoming irate


2010-01-07:

06:05 < tanuk> mezcalero: What is the reason for loading the X11
properties after client.conf? To me it would seem logical to prefer
client.conf settings over the X11 properties. The only issue I see is
setting autospawn = yes in client.conf while the X11 props say that a
remote server should be used. I would fix it by making "autospawn = yes"
a no-op - the option could only be used to disable autospawning.
06:37 < tanuk> mezcalero: When I wondered about this yesterday, coling
said that the idea was that if client.conf has a remote server set, the
local daemon will never get started so there are no X11 props either.
06:39 < tanuk> But isn't the local daemon nowadays normally started
directly, not via the autospawn mechanism, and thus without consulting
client.conf first?
06:40 < tanuk> And anyway, I don't see why the order shouldn't be "first
X11 props, then override with client.conf", just in case?
16:23 < mezcalero> tanuk: we treat x props mostly identical to
environment variables
16:23 < mezcalero> and env vars naturally should override client.conf i
think
16:24 < mezcalero> alread transitively because they themselves are
controlled via an env var which is $DISPLAY
16:26 < mezcalero> tanuk: the start-pulseaudio-x11 script should
probably refuse to do anything if there is already a server configured
by some means
16:26 < mezcalero> tanuk: there was a discussion about that a while back
16:26 < mezcalero> tanuk: and even a bug report
16:26 < tanuk> Bug #606
16:26 < tanuk> ?
16:26 < pulsator> tanuk: Ticket #606:
http://www.pulseaudio.org/ticket/606 Owner: lennart; Status: new;
Component: daemon and Summary: [PATCH] pulseaudio systemwide is a pain
16:26 < tanuk> Colin pointed to that, I didn't read it completely,
though.
16:27 < mezcalero> tanuk: "pulseaudio --start" should probably use
client-conf.c and check if there is anything overriding the server name
16:27 < mezcalero> and if so exit cleanly
16:27 < mezcalero> patch should be simple to do
16:27 < mezcalero> i know that some distros patch start-pulseaudio-x11
to check for $PULSE_SERVER
16:27 < mezcalero> debian does afaik
16:27 < mezcalero> but that doesn't cover x11 props of course
16:28 < coling> or client.conf
16:28 < coling> *nor
16:28 < coling> the exit code would have to tell e.g.
start-pulseaudio-x11 not to try and run the pactl commands tho'
16:29 < coling> either that of have a "pulseuadio-is-local" utility to
use in scripts like that.
16:29 < mezcalero> coling: nah, module-x11-cork-request should still be
loaded
16:29 < mezcalero> as should module-x11-xsmp
16:29 < coling> Actually yeah so it should...
16:30  * coling didn't think :)
16:30 < mezcalero> and module-x11-publish may be loaded too
16:30 < mezcalero> shouldnt hurt
16:31 < mezcalero> so yes, all that is missing is a tiny patch that
makes --start use client-conf.c and client-conf-x11.c to verify that
there is no local config
16:31 < mezcalero> and we should be done
16:33 < tanuk> So --start should just check if there's a server
configured, and if there is, return 0 and not start the server? I can do
that.

-- 
Tanu Kaskinen