[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:

<code>
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 = 
translate_error(pa_context_errno(p->context));
                                 goto finish_locked;
                         }

                         for (;;) {
                                 pa_operation_state_t state = 
pa_operation_get_state(o);

                                 if (state == PA_OPERATION_DONE) {
                                         canceled = FALSE;
                                         break;
                                 } else if (state == 
PA_OPERATION_CANCELED) {
                                         canceled = TRUE;
                                         break;
                                 }
                 /* !!! We are hangining in the wait below !!! */
pa_threaded_mainloop_wait(p->mainloop);
                         }
</code>

The callback is defined as:

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

This seems to be modeled over
http://freedesktop.org/software/pulseaudio/doxygen/threaded_mainloop.html


So, two questions:


(1)

It does not seem that play_sample_cb locks the mutex
p->mainloop->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 ...

QUESTION:
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.


(2)

QUESTION:
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.


/Henrik




More information about the pulseaudio-discuss mailing list