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