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

[Michael Niedermayer]

On Mon, Feb 20, 2012 at 09:32:11AM +0100, Nicolas George wrote:
> Le primidi 1er ventôse, an CCXX, Michael Niedermayer a écrit :
> > Well, but this mathematical model doesnt really match reality
> > 
> > My patch would exactly calculate the rate while leaving the actual
> > values to a first order filter. In the model that the rate is constant.
> > If its not constant but instead piecewise constant, like in your test
> > here, it of course doesnt work nearly as well.
> > 
> > One could create a filter that performs better on such piecewise
> > constant rate input than any clasical second-order filter.
> > That no doubt would perform worse then on for example piecewise
> > polynomials
> > 
> > And any functional classic second-order filter would catastrophically
> > break down in case some large discontinuities or outliers are
> > introduced.
> > 
> > I think we should first find a reasonable model for the data and noise
> > before trying to find a filter that seperates them
> > 
> > The 2nd order Timefilter seems to assume that noise is mostly high
> > frequency and data is mostly low frequency.
> > 
> > My patch would in addition have assumed a near constant rate.
> > 
> > The discontinuities in your test would indicate though that there is
> > some non zero high frequency data in addition to the low frequency
> > and neither filter handles this well as they try to discard noise by
> > discarding high frequency. Blurring the data.
> > This should become quite catastrophic in case of large discontinuities
> > as  these would have very large high frequency components that actually
> > would far exceed the noise.
> > I thus think if the filter is intended to handle discontinuities it
> > has to do more than just a 2nd order filter. Like detecting such
> > discontinuities and reseting its state or adjusting its coefficients.
> 
> Obviously, the more rigid the model, the more efficiently it is possible to
> filter.
>

> But I believe your proposal is too rigid to model some real-time
> phenomenons.

it was not meant to be a final solution, more to show what improvments
would be possible in the restricted case


> 
> (Additionally, I believe it has the flaw of trusting the very first point
> too much: for the same model, a least-square linear fit on all the points
> would probably be more accurate; but that is another matter.)
> 
> Discontinuities are a severe problem and are easily detected: a special case
> for them could be added to any kind of filter.
> 
> Speed changes, on the other hand, are much harder to detect, and I believe
> they are a real occurrence:

fully agree to all above


> I mentioned ntpd, but they also may be due to
> some power-management systems, such as cpufreq.
> 
> I believe the tests I posted show that the second order filter behaves
> pretty well on speed changes. It can not detect them instantaneously, of
> course, nothing could short of knowing about them from a side channel. But
> the result is always within reasonable values and converges in a very short
> time.
> 
> In fact, I find the current second order timefilter very good in most cases.
> The only problem is that it is designed for constant small intervals, which
> does not suit ALSA. That is as much ALSA's fault that the timefilter's. And
> the solution of slicing updates small constant steps, although not
> mathematically satisfactory, is simple and straightforward, and works pretty
> well.

Iam not opposed to using a 2nd order filter with additional handling
for discontinuities. Though IIRC the new filter contains a loop and
this might cause it to eat more cpu cycles than would be ideal.


[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- 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/20120220/54f878df/attachment.asc>