Live Audio Playback from Microphone Goes Silent on Windows wasapi
Submitted by Michael MacIntosh
Link to original bug (#797329)
Description
Created attachment 374015
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.
Attachment 374015, "An excerpt of the ringbuffer:5 debug logs.":
ringbuffer_5_debug_excerpt.txt
Version: 1.14.4