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

Fons Adriaensen fons
Tue Mar 3 21:45:00 CET 2009


On Tue, Mar 03, 2009 at 09:18:39PM +0100, Olivier Guilyardi wrote:

> Michael Niedermayer wrote:
>
> > ive read over it mostly now, there is no hint of why the
> > parameters are locked together.

There is, and it's not a hint but a very clear statement.
See the last sentence of section 3. 
There is no good reason to set the damping to another
value, critical damping ensure the loop will settle as
fast as possible for the given bandwidth. Less damping
and it will 'ring', more and it will be slower to settle
without improving performance.

> > And about users, i did not mean the end user should mess with the parameters
> > but the optimal values clearly depend on the hardware and there are 2 not 1
> > from which 2 can be found.

See above.

> > It surely would make sense to be able to set them
> > based on the kind of audio hw.

Only the bandwidth should depend on the hardware.

> > Besides strictly speaking the optimal values of these parameters are non
> > constant. To see why just consider that the exact samplingrate is initially
> > not known exactly and has to be estimated first

Filter parameters do not in any way depend on the
(small) error on the sample rate. Again, using 
critical damping will ensure that the filter will
adapt to a sample rate error as fast as can be done
given the bandwidth.

> > also the authors of the paper test the filter meassuring
> > its jitter, i dont see in how far this is meassuring the
> > quality of the filter,

What do you mean by 'quality' ? 

> > its easy to apply  heavy enough filtering to reduce the
> > jitter between timestamps to whatever value one desires
> > this though does not make the timestamps actually represent
> > reality.

Of course not. Reality includes the jitter, and all this is
supposed to reduce that. 

> > Just consider that the jitter was truly due to inaccurate
> > sampling times in the hardware.

You are confusing two things called jitter:

1. the one on sample times, determined by the
quality of the hardware and completely irrelevant
in this context,

2. the one the time when the system handles the
soundcard interrupt, which the one the DLL is
meant to improve.

Ciao,

-- 
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

O tu, che porte, correndo si ?
E guerra e morte !




More information about the ffmpeg-devel mailing list