Created attachment 226869 [details] [review]
media keys: Move volume initialization to an idle too

fwiw, ubuntu ships a slightly smaller patch that only moves the open call to the idle

Review of attachment 226869 [details] [review]:

Don't like this.

pa_context_connect() is supposed to be async. If it isn't, there's a bug in the PA libraries.

Arun, Colin, why would pa_context_connect() block on startup?

What's actually happening here? I don't see any debug/log, just a patch and not too much description of the problem itself. What is the definition of "significant" here - i.e. how long is the delay?

pa_context_connect() will try and establish connections and will only return if a connection succeeds or fails. If we have several servers to try (e.g. local socket, tcp etc.) then it could conceivably take some time for this list to be worked through - I can't remember the default TCP connection timeout but depending on network config it could certainly result in some delay under some circumstances.

That said, I guess the problem here would be the fact that PA is autospawning and thus the connection won't complete until after the server has fully spawned and a connection established. If this is the case, then one of the modules could be holding things up more than it should, in which case you could try commenting out modules in default.pa until the delay disappears. My first guess here would be bluetooth stuff as I remember seeing delays related to this myself some time ago at the gdm stage. That turned out to be a dbus policy problem IIRC where the gdm user was not permitted to connect to some bluetooth bits - I forget the details but if it turns out to be BT related, let me know and I'll try and remember what it was in more detail.

Failing the above giving an immediate solution, are you seeing the delays initially when gdm loads or only when you really log in? i.e. does it delay gdm's start or just the real user? If the latter, then perhaps the start-pulseaudio-x11 script is being launched in the gdm session via XDG autostart (pulseaudio.desktop). It shouldn't be processed as far as I understand it, but someone did mention this was happening for them that long ago on IRC. When this happens, the real user's session is launched it inherits the X11 properties and then the PA context fails to connect to the right PA. This situation would obviously cause problems, but I'm not sure it would cause actual delays, but it's certainly possible with some setups.

Those are some ideas of the top of my head.

(In reply to comment #5)
> What's actually happening here? I don't see any debug/log, just a patch and not
> too much description of the problem itself. What is the definition of
> "significant" here - i.e. how long is the delay?
<snip>

All that to tell us that pa_context_connect() isn't actually async, correct? Do we have an async equivalent?

(In reply to comment #6)
> All that to tell us that pa_context_connect() isn't actually async, correct?

Actually no, "all that" and I think I've probably not got it all totally correct.

There are circumstances where I think it could behave in a non-async manner (e.g. one would be by configuring the preferred server address in client.conf to be a hostname and compiling PA without libasyncns support, it could in theory, block on the getaddrinfo() or gethostbyname() hostname lookups of the first client in the server list. Another would be if client.conf contained a malformed server address, the autospawn would happen before return and thus result in horrible blocking while waiting for the server to start), but under most normal circumstances it should behave asynchronously.

So to analyse the problem noticed here, can you hack your system to set PULSE_LOG=99 and see if there is anything that can be gleaned from the log output and see if the server addresses are fishy in some way.

Keep in mind what I said in my previous comment about start-pulseaudio-x11 being run in the gdm context and accidentally injecting a PULSE_SERVER X11 root window property. That would certainly delay start up, even if it *should* behave async AFAICS. Worth checking tho' (xprop on the X11 root window when gdm is running should be enough to rule this out).


I'll open a bug regarding the fact that pa_context_connect() will behave non-async when a malformed address is present in client.conf as that should really be fixed.

I hope I've analysed the codepaths properly this time. Arun can you double check?

I don't think we really want pulseaudio to start up in the critical path of login - we're not playing a login sound, so why pay this price ? If you look at bootcharts, starting pulseaudio is not cheap.

(In reply to comment #8)
> I don't think we really want pulseaudio to start up in the critical path of
> login - we're not playing a login sound, so why pay this price ? If you look at
> bootcharts, starting pulseaudio is not cheap.

All the h/w probing is really not nice and certainly takes time :(

(In reply to comment #8)
> I don't think we really want pulseaudio to start up in the critical path of
> login - we're not playing a login sound, so why pay this price ? If you look at
> bootcharts, starting pulseaudio is not cheap.

We can have sounds almost immediately on startup, and the sound icon flickering isn't so nice either.