audiobasesrc: Re-timestamp slave method introduce latency
Submitted by Nicolas Dufresne @ndufresne
Link to original bug (#795443)
Description
So, to workaround https://bugzilla.gnome.org/show_bug.cgi?id=795442 I started using re-timestamp slave method. As I'm using an audiomixer or an audiointerleaver downstream, I can rely on these to handle the skew for me. So this method worked in maintaining a constant latency. The problem that I faces though is that between the first and the second called to GstAudioBaseSrc:create() there is a large delay (around 130ms in my case).
read(sample 0)
130ms later ...
read(sample 1)
As the segtotal is pretty large (320ms) all this data get buffered in the ringbuffer, and remains. I've made a quick hack to get going, basically I would never let the read-head be further then 2 segments from the most recent, but this had a side effect, which is that the audio source can no longer accumulate latency.
If it wasn't of the re-timestamp, what would happen is that all buffered segments would get pushed, but would be late according to their timestamp, but with the re-timestamp, which is a bit of a hack method really, they all will be right on time. Investigating this delay seems useful, but it would be nice to improve the re-timestamp slave method so it does not have this side effect.