alsasrc concurrency question

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

alsasrc concurrency question

Frederik
HI,
I was debugging a problem related to alsasrc element, when I observed these log lines from gstreamer during disposing the alsasrc element
0:21:22.652372808 [334m  879[00m  0x127ea80 [37mDEBUG  [00m [00m                alsa gstalsasrc.c:1023:gst_alsasrc_reset:<alsasrc39>[00m drop
0:21:22.653105297 [334m  879[00m  0x127ea80 [37mDEBUG  [00m                 alsa gstalsasrc.c:1025:gst_alsasrc_reset:<alsasrc39>[00m prepare
0:21:22.654631315 [334m  879[00m 0xb193aef0 [33;01mWARN   [00m                 alsa gstalsasrc.c:861:xrun_recovery:<alsasrc39> xrun recovery -32: Broken pipe
0:21:22.698214407 [334m  879[00m  0x127ea80 [37mDEBUG  [00m [00m                alsa gstalsasrc.c:1027:gst_alsasrc_reset:<alsasrc39>[00m reset done
0:21:22.711734932 [334m  879[00m 0xb193aef0 [33;01mLOG    [00m [00m                alsa gstalsasrc.c:938:gst_alsasrc_get_timestamp:<alsasrc39>[00m ALSA timestamp : 0:22:26.514216229, delay 0

Seems like two threads are accesing the alsa driver object at the same time.
Going through the alsarc source code, I can see that gst_alsasrc_read locks  just before reading but releases the lock before calling gst_alsasrc_get_timestamp ( which eventually will call xrun_recovery ).
Shouldn't release the lock be placed just after gst_alsasrc_get_timestamp or is there anything I'm missing here ?

Best Regards
Frederik