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 :/ > 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. > 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 This feature *might* mean I can stop computing PULSE_SERVER, and just set it statically. Let's see... > 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, and that it should get set after PA itself starts. How strange. (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.) (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.) > 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.
