audiobasesrc: Re-timestamp slave method introduce latency
Submitted by Nicolas Dufresne
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).
130ms later ...
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.