a proposal for a new alsasink slave method

[Charlie Laub]

I managed to find the name of the slope estimation method I described below:
it is the Thiel-Sen estimator:
https://en.wikipedia.org/wiki/Theil%E2%80%93Sen_estimator
Looks like it can be done in order 2N complexity, as new points become
available.

There is code floating around the web for various implementations of this,
but it should not be difficult to code up from scratch. 



-----Original Message-----
From: gstreamer-devel <gstreamer-devel-bounces at lists.freedesktop.org> On
Behalf Of Charlie Laub via gstreamer-devel
Sent: Wednesday, July 21, 2021 2:19 PM
To: 'Discussion of the development of and with GStreamer'
<gstreamer-devel at lists.freedesktop.org>
Cc: Charlie Laub <charleslaub at sbcglobal.net>
Subject: a proposal for a new alsasink slave method

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.

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.

-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