[Bug 765115] New: alsasink: single segment audio glitch after 200ms at startup

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=765115

            Bug ID: 765115
           Summary: alsasink: single segment audio glitch after 200ms at
                    startup
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: thaytan at noraisin.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

with some audio sinks (alsasink), we can get a single segment glitch at startup
after processing 200ms of data, because the GStreamer ringbuffer is sized
exactly the same as the target hardware ringbuffer.

alsasink starts pushing samples to ALSA after the ringbuffer fills up /
prerolls with 200ms (default buffer-size) of samples. At that point, it writes
samples as quickly as possible to ALSA until the write() call to ALSA blocks.

What that means is we read and write 20 10ms segments *very rapidly* to the
audio device, and then on the 21st write it will block for ~10ms until the
hardware plays 1 segment. What gets written in the 21st segment *may* be
correct audio, if upstream was given a timeslice to write those samples, but
commonly (especially on single core machines), alsasink gets to the 21st
segment and it's not ready yet, so it generates a silence fragment and *then*
blocks writing that out.

If upstream is then woken up, it will find that it is too late and drop that 1
segment.

The simple fix is to allocate 1 more segment in the GStreamer ringbuffer for
upstream to write into, which uses slightly more memory but otherwise doesn't
affect overall playback latency since the ringbuffer in the hardware is still
configured with 20 segments.

Most audio sinks need that extra segment to avoid this glitch. I think
pulsesink where we write directly to their ringbuffer is the only one that
doesn't.

I propose we make the ringbuffer expand spec->segtotal += 1 in
gst_audio_ring_buffer_parse_caps() when indicated by setting a flag using a new
gst_audio_ring_buffer_enable_extra_segment () function (or so).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.