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

[Olivier Guilyardi]

Michael, Fons has made the following answer on jack-devel to your comments about
his paper:

Fons Adriaensen wrote:
> 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,
>