GNOME Bugzilla – Bug 781030
alsasrc sometimes causes hanging.
Last modified: 2017-05-23 09:30:08 UTC
The Alsa driver requires serialized handling from clients on a given device handle, meaning that the client need to implement its own locking scheme for access. From an application perspective, alsasrc is the place where this should be handled. There are mutex locking in alsasrc, but it is not complete and seem to leave some openings for trouble. A fix is suggested to add mutex locking on a few more functions. It is an observed problem and the suggested patch solves it.
Created attachment 349462 [details] [review] suggested patch Initial suggested patch.
Created attachment 349463 [details] [review] alsasrc added mutex locks Original Patch
Did you check if the same problems are also in alsasink?
Also everything where you added the mutex would be called from the streaming thread if I'm not mistaken. Which other code paths can cause ALSA functions to be called from another thread at the same time?
The calls are typically from the ringbuffer in another thread. Example situation: One thread is in gst_audio_ring_buffer_release Another is trying to do gst_alsasrc_get_timestamp() The ringbuffer release code go via cb interface to eg. unprepare. There is a race situation that can be solved by using the present mutex in GstAudioSrc. I have addressed a specific issue seen in our devices but it should perhaps be in place for alsasink as well.
When considering this patch further, we wish to withdraw it. It solve our problem, but we will consider another solution where the race conditions we see are altogether avoided (same thread). Please remove or close this ticket.