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

[Colin Guthrie]

'Twas brillig, and Nix at 29/05/10 11:19 did gyre and gimble:
> Things get clearer. (Sorry for the delay: jobhunting hell.)
> 
> On 17 May 2010, Tanu Kaskinen told this:
> 
>>              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.
> 
> As opposed to now, where I do in fact run start-pulseaudio-x11, and had
> no idea why it wasn't working until I looked at the source code :/

Yeah, clearly that is not a good situation :s

>> 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.
> 
> Ah, yes, I forgot about this feature. This surely makes it even *more*
> important that the server starts when the client asks it to, because you
> might be starting a server earlier on the preference list than the one
> you're already using. But your comments below make the rationale clearer:
> I just wish there was a less aggravating way to do it.


Well that's a tricky situation to resolve. If I ssh to another machine,
I specifically want the earlier (higher preference) servers in the list
to fail so that I fall back to network and get the sound out of my local
machine. The last thing I want is for PA to think "Hmm, I'm connected,
but not to the first server" and try and spawn one.

That said, local socket paths in the PULSE_SERVER var are prefixed with
the dbus machine id. If the machine id == this machine, and we cannot
connect to the server, it's pretty likely that we need to start a local
server. I not sure under what circumstances this logic would fail -
su'ing to another user while the X11 props are there and the server died
will break, but it's quite a corner case.


>> 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.
> 
> Aha, so the idea is that PULSE_SERVER should specify your local server,
> then every remote server it might possibly want, in preference order,

More or less by by default, it is used to specify the *same* PA server,
accessible via different means. e.g. local, tcp6 and tcp4. That way
local apps, running locally will use a local socket and remote apps
running after SSHing to a remote machine will use some tcp variant.

> and that it should get set after PA itself starts. How strange.

How else can we know what the patch to the local socket will be without
starting PA (or at lease using the client libraries)? These settings are
a reflection of the running server, not a pointer to where it should be.
If the server crashes, the configuration *should* die with it, but that
is not always possible. The x11-publish module will remove the X11
properties when shut down cleanly, but a crash......


> (Also
> sort of impractical if you have a server that serves several hundred
> desktops: what's PULSE_SERVER going to do, specify them all? The order
> would differ between users, so in pradtice you still need to dynamically
> compute it.)

Not sure what you mean by a "server that serves several hundred
desktops". On such a scale, it's very unlikely that the desktop machine
itself would be responsible for starting the daemon and thus any
configuration would have to be written on top of PA, not be part of it.
But perhaps I don't understand your setup?


> (But still, a server that won't start because an environment variable
> is set telling *client* programs where to look for that very server?
> What a horrible idea.)


I don't necessarily disagree, but the same logic that applies to
autospawning, (triggered by the *client*) should really apply to how the
server itself is started too, so there is some logic in keeping them
tied together like that.


>> 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
> 
> Agreed. I suspect the right way to detect this is to *try to connect to
> it*, not just to use PULSE_SERVER as an (easily erroneous) promise that
> the server is already running. It's sort of strange for a PA server to
> do this (which is normally the responsibility of the client), so perhaps
> what we need is a pulseaudio ping program (part of pactl probably), and
> have start-pulseaudio-x11 run that to see if the server is already up,
> rather than have pulseaudio itself check for any such thing. It takes
> a tiny bit longer, but who cares if startup forks one more time? It's
> not as if we start up every five minutes.

Ohh, have you not read Lennart's systemd stuff - beware the forks!!! :p

But seriously, I think the pulse server variable should be checked to
see if it points at a local local socket. If it does and we cannot
connect, then we should probably try and autospawn, but with some
safeguard to protect the "su'ing to another user and the pa server of
the X11 root window owner has crashed" scenario.

That way the typical use case of single user, PA daemon crashed, x11
props left to linker will not prevent a respawn of the server.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]