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