GNOME Bugzilla – Bug 797329
Live Audio Playback from Microphone Goes Silent on Windows wasapi
Last modified: 2018-11-03 14:36:46 UTC
Created attachment 374015 [details] An excerpt of the ringbuffer:5 debug logs. I am running into audio playback issues in the latest versions of gstreamer. I am using 1.14.4 on windows 10 but have also experienced this issue on windows 7. It is most pronounced with wasapisrc and wasapisink, but I have experienced this issue with directsoundsrc and directsoundsink and combinations thereof. My current workaround (that I am still testing, but getting better results) is using directsoundsrc and directsoundsink with double the default buffer times and latency times. With wasapisrc, playback via wasapisink will go silent after a certain amount of time or go choppy. The audio will usually play for a few seconds, go silent for about 15-20 seconds, then play again for another 3 seconds. It usually repeats this process until it will eventually cut out completely. A simple pipeline to reproduce this issue would be something like: wasapisrc ! queue ! audioconvert ! audioresample ! wasapisink (the audioconvert and audioresample are probably superfluous) This is assuming you are using headphones and have a microphone plugged in, so it can select them as default devices. Running the pipeline with gst-debug="ringbuffer:5" gives log output that appears to indicate that the read pointer is getting ahead of the write pointer in the ringbuffer (the diff goes negative and the sink stops playing the audio). I do not get this issue with file or network sources of audio. It is more common / severe with wasapisrc over directsoundsrc (it takes much longer for directsoundsrc to play nothing). I have tried increasing the latency-time and the buffer-time of wasapisink, which does improve the audio quality quite a bit, however it still runs into issues. Attached is an excerpt of the ringbuffer:5 log. In this section the diff goes to -20 out of 20 (segtotal). I presume that this negative diff causes audio to not play since it sets skip to true, and doesn't copy anything into the ringbuffer. I was also noticing negative diffs with the audiosrc ringbuffer, and I can provide logs of that as well. This bug might be a duplicate / related to https://bugzilla.gnome.org/show_bug.cgi?id=796354 However, they do not make any mention to silence. Let me know if there is anything else I can provide / clarify.
I'm having the same issue. Using the following pipeline wasapisrc ! wasapisink the sound will play for about 3 seconds and then goes silent. 032A0618 WARN wasapisrc gstwasapisrc.c:589:gst_wasapi_src_read:<wasapisrc0> WASAPI reported glitch in buffer 032A0438 WARN audiobasesink gstaudiobasesink.c:1491:gst_audio_base_sink_skew_slaving:<wasapisink0> correct clock skew -0:00:00.021788450 < -+0:00:00.020000000 032A0438 WARN audiobasesink gstaudiobasesink.c:1491:gst_audio_base_sink_skew_slaving:<wasapisink0> correct clock skew -0:00:00.023249205 < -+0:00:00.020000000 032A0438 WARN audiobasesink gstaudiobasesink.c:1491:gst_audio_base_sink_skew_slaving:<wasapisink0> correct clock skew -0:00:00.020448680 < -+0:00:00.020000000 032A0438 WARN audiobasesink gstaudiobasesink.c:1491:gst_audio_base_sink_skew_slaving:<wasapisink0> correct clock skew -0:00:00.020098942 < -+0:00:00.020000000 032A0438 WARN audiobasesink gstaudiobasesink.c:1491:gst_audio_base_sink_skew_slaving:<wasapisink0> correct clock skew -0:00:00.020282826 < -+0:00:00.020000000 032A0438 WARN audiobasesink gstaudiobasesink.c:1787:gst_audio_base_sink_get_alignment:<wasapisink0> Unexpected discontinuity in audio timestamps of -0:00:00.040000000, resyncing I'll try to investigate it later, but would be nice to receive a feedback here. By settying setting sync=false for wasapisink, the pipeline works fine (the audio isn't interrupted).
Also setting the slave-method=2 (NONE) for wasapisink or setting provide-clock=false for waspisrc seems to solve these problems as well: wasapisrc ! wasapisink slave-method=2 or wasapisrc provide-clock=false ! wasapisink I'm not sure what is going on, but it seems related to the clock :P
using wasapisrc ! wasapisink sync=false doesn't work for me, it still goes silent periodically, and usually when it starts this behavior, it will eventually go silent permanently, usually in about 20 minutes sometimes longer depending on hardware. provide-clock=false on the wasapisrc sounds worse than the sync=false pipeline for me. slave-method=2 on the sink sounds fine at first, then after 90 seconds it goes silent. The silence appears to be caused by the ring buffer getting starved, which might be related to the warning I am getting: captured too many frames: have 448, want 447 However even in setups where it is not producing that error message, like: wasapisrc use-audioclient3=true ! queue ! wasapisink I still get the silence. So I am assuming the warning message is a different error. Also the queue is load-bearing as without it you will get the message "Can't record audio fast enough".
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/806.