[FFmpeg-devel] [Jack-Devel] [PATCH] libavdevice: JACK demuxer
Thu Mar 5 19:11:46 CET 2009
Michael Niedermayer wrote:
> On Thu, Mar 05, 2009 at 01:15:21PM +0100, Fons Adriaensen wrote:
>> If the sequence of measured times is t_i, then t_1 - t_0
>> *could* give an first estimate of the true sample rate.
>> Most sound cards (even the cheapest ones) are within
>> 0.1% of the nominal value. Wich means the random
>> error on t_1 - t_0 (the jitter) will be much larger
>> than the systematic one, and the sample rate computed
>> from the first two value is useless. This will apply
>> to any trick you may want to use to get a 'quick'
>> value for the sample rate error.
> I would suspect, though dont know that the samplerate error
> stays the same (assuming similar temperature) thus remembering
> it from last time would make sense. The code though that was
> submitted even explicitly overwrites the estimate by the nominal
> value on reset() ... (not sure if the paper says anything about this
No, ff_timefilter_reset(), which is meant to be called in case of xrun, doesn't
reset the second integrator state (e2 below) anymore in my timefilter patch
Fons' paper says:
The first iteration sets initial conditions. This is executed in the first
process cycle when JACK starts, or after an xrun:
// init loop
e2 = tper;
t0 = read_timer();
t1 = t0 + e2;
But I think it indeed makes no sense to lose the experience accumulated by the
filter during the cycles that preceded the xrun.
More information about the ffmpeg-devel