[pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

Henrik /KaarPoSoft henrik at kaarposoft.dk
Tue Dec 25 12:13:20 PST 2012

Dear all,

I have once again looked at this problem...

libcanberra contains this function:

int driver_play(/* ... */) {
     /* ... */
         if (name && cache_control != CA_CACHE_CONTROL_NEVER) {
         /* ... */
                 for (;;) {
             /* ... */
                         /* Let's try to play the sample */
                         if (!(o = 
pa_context_play_sample_with_proplist(/* ... */) {
                                 ret = 
                                 goto finish_locked;

                         for (;;) {
                                 pa_operation_state_t state = 

                                 if (state == PA_OPERATION_DONE) {
                                         canceled = FALSE;
                                 } else if (state == 
                                         canceled = TRUE;
                 /* !!! We are hangining in the wait below !!! */

The callback is defined as:

static void play_sample_cb(pa_context *c, uint32_t idx, void *userdata) {
/* ... */
         pa_threaded_mainloop_signal(p->mainloop, FALSE);

This seems to be modeled over

So, two questions:


It does not seem that play_sample_cb locks the mutex

I have not found any place in the code where the mutex is locked,
but then again I am no expert, and may have overlooked it ...

Should play_sample_cb (and the example for threaded_mainloop)
lock the mutex ???

It seems to me, that if the mutex is not locked, we risk that
the play_sample_cb might be called before pa_threaded_mainloop_wait,
and play_sample_cb is thus waking nobody, and pa_threaded_mainloop_wait
would then wait forever.


Is it safe to call pa_operation_get_state(o) in the main loop???

I would think that other thread(s) might set the
operation_state, as I have not yet found the code which would
protect against this.


More information about the pulseaudio-discuss mailing list