[FFmpeg-devel] [Jack-Devel] [PATCH] libavdevice: JACK demuxer

[Olivier Guilyardi]

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
> case)

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
version 0.3:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-March/064483.html

Fons' paper says:

<citation>
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;
</citation>

But I think it indeed makes no sense to lose the experience accumulated by the
filter during the cycles that preceded the xrun.

--
  Olivier