a proposal for a new alsasink slave method

[Nicolas Dufresne]

Le mercredi 21 juillet 2021 à 14:18 -0400, Charlie Laub via gstreamer-devel a
écrit :
> I see that the slave methods are still not very well developed. Judging by Nicolas's response below, evidently resampling is no longer supported, leaving only skewing. I had a problem with this a year or two ago when the playback timing was skipping around frequently, making audible slewing every few ten to tens of seconds. Here are some thoughts on how this could be solved without resorting to resampling.

The resampler there is very naive and never actually worked. Though, it looks
like most of the issue is not about skew vs resampling, it's the data that is
way too agressive.

> 
> I propose a method where the offset was determined over a relatively long period of time (e.g. seconds to a minute). This is much slower than trying to correct the offset within a single frame. For example, I would like the playback offset to be less than 1 msec between machines that are NTP synchronized to e.g. 100usec or better to some local timeserver (I do this on my LAN now). Setting the drift tolerance property to 1msec does not improve the performance.
> 
> The instantaneous offset data often contains a lot of noise due to packet latency on the network or local clock rate changes, and determining the long term trend is really the only way to filter out the short term noise/error. Putting the offsets through some kind of filter would be very useful - simply averaging N data points or simple low passing will introduce too much lag into the output, so a more robust method like Savitzky-Golay would be best. If obtaining the slope of the data within some interval is useful, there is an excellent technique (I forget the name of it) in which you calculate all pair-wise slopes for all points within the interval. Then you take the median (not mean) from this set of slopes as the estimate of the true slope. It's very robust and resistant to outliers, noise, etc. The calculation initially seems to be of N^2 complexity, but in reality only N slopes must be calculated for the most recently added data point, and then the set re-ordered to find the ne
>  w median, so the task is not that demanding. This can be done over some interval that is characteristic of the typical velocity at which the system is changing its rate, e.g. because the local clock is speeding up or slowing down, etc. This might be seconds to a minute or more. 
> 
> Once a good estimate of the slew rate of the system is known and is free of noise, then corrections via a skew would be small and relatively innocuous. This would eliminate the large back and forth skewing that can happen currently with the skew method and should be more efficient than resampling.

Note that drift rate and alignment estimation is mostly common code along with
the various correction method. For many users, being off always is better then
always having an initial correction.

To be able to handle this better, you'll quickly found that the layers of
abstractions in place are in the way. Most of this is ABI, so perhaps you should
also consider create new base classes.

> 
> -Charlie
> 
> -----Original Message-----
> From: gstreamer-devel <gstreamer-devel-bounces at lists.freedesktop.org> On Behalf Of Nicolas Dufresne via gstreamer-devel
> Sent: Wednesday, July 21, 2021 1:18 PM
> To: Discussion of the development of and with GStreamer <gstreamer-devel at lists.freedesktop.org>
> Cc: Nicolas Dufresne <nicolas at ndufresne.ca>; Michiel Konstapel <michiel at aanmelder.nl>
> Subject: Re: Inconsistent/variable delay between USB and onboard alsasrc
> 
> skew is pretty much the only working option in alsasink atm, play with alignment-threshold and drift-tolerance in order to get something closer to 4ms.
> 
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel