[pulseaudio-discuss] Autospawn Contention

[Colin Guthrie]

Hi,

I'm trying to debug a really annoying problem and I think I've come
across a bit of a race condition during startup/login relating to
autospawning.

If an application probes for PA before enabling support for it, and if
PA is not running then it will try to autospawn it. Sensible so far, but
if, during the time between trying to connect and running the autospawn,
some other application has jumped in and grabbed the autospawn lock, the
first application fails to launch PA and thus fails to connect and thus
PA is detected as not available.

This can then cause problems with sound devices being hogged etc. etc.
if the app in question falls back to direct output or similar.

All in all, it's pretty messy.

Is there something we can do to prevent this problem? I'm thinking like
something to detect the reason for failure as being autospawn lock
failure. This autospawn code could then check for an autospawn lock
(owned by another process) and wait for it to be released then say "OK,
I'm done" and attempt the connection again (knowing that someone else
has done (or at least tried!) the autospawn for us).

Now, the confusing thing is that I believe that this whole process is
already done. The autospawn lock is acquired in a blocking capacity.
This means that unless the autospawn lock totally fails (which I believe
is not likely?), it will be acquired. And if it is acquired, then
running pulseaudio --start should succeed fine if it's not already running.

Basically, I've had a look at the autospawn locking stuff and I can't
see anything immediately obvious that would result in a failure during
initial connection unless the whole lock stuff fails.


FWIW, the problem I'm trying to debug is here:
https://bugs.kde.org/show_bug.cgi?id=232068

The problem I find is that the backtrace indicates that PulseAudio
support has NOT been detected - e.g. it tried to connect but then
failed. However, a connection is clearly running in another thread.

One thing that may be relevant is that this process creates two PA
connections and that may in some capacity get in the way (although the
initial probe should happen before any attempt to connect to the daemon
for the actual audio output).

Now there is the crash itself too, which is probably unrelated, but
should be fixed too.

The main problem I'm interested in is the fact that PA is not being
detected as available properly.

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/]