alsasrc concurrency question

[Frederik Leth]

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 [00m
     alsa gstalsasrc.c:1025:gst_alsasrc_reset:<alsasrc39>[00m prepare
0:21:22.654631315 [334m  879[00m 0xb193aef0 [33;01mWARN   [00m [00m
       alsa gstalsasrc.c:861:xrun_recovery:<alsasrc39> [00m 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211119/4c6cc137/attachment.htm>