[FFmpeg-devel] [PATCH] ALSA: fix timefilter divergence

Nicolas George nicolas.george at normalesup.org
Thu Feb 16 23:05:24 CET 2012


L'octidi 28 pluviôse, an CCXX, Michael Niedermayer a écrit :
> what we have are noisy time values at arbitrary time intervals
> we also know these time intervals to a pretty good approximation.
> There is a systematic error in the time intervals due to clocks not
> being exact while i assumed that this systematic error is sufficiently
> close to constant over time. That is 44100 hz may actually be
> 44098 but wont drift slowly around between that and 44102. If this
> assumtation is wrong the filter becomes less optimal but
> should not catastrophically fail.
> 
> The way i implemented that is quite simply to take the first and
> last timestamps and the "number of samples" to get the true sample
> rate and use this instead of a exponentially decaying average.

I see. I thought it may have been something more subtle.

> I dont think either of the filters behaves very well in this case
> having the timestamps significantly wrong for a long time and then
> correcting that suddenly likely leads to some issues.

Actually, the original one does behave pretty well. That is what makes these
control loops tricky: filtering out random noise is easy; doing it while
adapting quickly to long term changes is hard.

The current time filter is based on a second-order differential equation,
with coefficients tweaked to ensure quick convergence. At first glance, your
changes turns it into a first order differential equation, or something
similar.

In December, when I first looked at the issue, I plotted the behaviour of
the current filter, with a 10% rate change in the middle: the result was
quite good (after fixing the sqrt(2) issue), it adapted to the new rate in
the time defined by the "bandwidth" parameter while keeping monotonic and
reasonably accurate.

The other implementation I proposed, based on a least-square linear fit and
an exponentially weighted moving average behaved almost as well, but took
twice the time to adapt to the new rate (for the same strength of noise
filtering).

I'll try to dig out the test programs and plots I did.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120216/2033473f/attachment.asc>


More information about the ffmpeg-devel mailing list