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