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

[Olivier Guilyardi]

Michael Niedermayer wrote:
> On Mon, Mar 02, 2009 at 03:18:51PM +0100, Olivier Guilyardi wrote:
>> Attached:
>> - jack demuxer patch version 0.7
>> - time filter patch version 0.1
>>
>> The later provides DLL time filtering as a libavformat patch (I'm not sure about
>> the Makefile changes).
>>
>> Michael Niedermayer wrote:
> [...]
>>> the 2 parameters that control the filter are locked together using a
>>> formular using sqrt() PI and others, while iam sure this can be proofen
>>> to be optimal in a idealized case its certainly not in all practical
>>> cases, the user should have the chance to set both independantly, and
>>> as a sideeffect the dependancy on math.h can then be droped
>> The parameters of the filter are a complex topic, which users shouldn't play
>> with IMO. Please fully read the pdf document mentionned earlier.
> 
> ive read over it mostly now, there is no hint of why the parameters are locked
> together.
> 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. It surely would make sense to be able to set them
> based on the kind of audio hw there is which doesnt mean that has to be done
> just that writing the code so it cannot be done is nasty

I changed that in the timefilter patch 0.3. Users now can play with internal
loop parameters.

> 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, after that, given reasonable
> quality hardware it is not going to change by a large amount IMHO.
> 
> 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, 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. Just consider
> that the jitter was truly due to inaccurate sampling times in the hardware.

I know Fons considers the jitter and the sampling rate error to be stricly
different. I think that his measures show the value of the jitter as he defined
it in his document.

> It seems the easiest way to test such filter would be to simulate timestamps
> + random noise sampled with a slowly drifting samplerate (simulating the
> effects of heat on the clock generator)
> With such simulation one could then test how close the filter can recover the
> true sampling times, because all things are exactly known in such a simulation
> this is harder with actual hardware where one doesnt know the true sampling
> times, but could probably done too given some high quality source signal

For you to get a better look on the the current implementation, here are some
benchmarks that a colleague and I made, with graphs and information about the
jitter correction factor, using libpendule on 4 different soundcards (on 2
computers):

http://www.samalyse.com/code/pendule/benchmarks

PS: I'll answer the ringbuffer specific questions separately

--
  Olivier