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

[Michael Niedermayer]

On Fri, Mar 06, 2009 at 09:45:38PM +0100, Olivier Guilyardi wrote:
> Attached: jack demuxer patch version 0.9
> 
> This patch fixes compatibility with the timefilter now that it has been applied
> to the svn trunk (as of r17850), and modified.
> 
> It also features safer protection against packet underruns.
> 
> Plus some comments and log messages improvements.
> 
> Warning: as of r17855, the timefilter is not activated in the trunk. For the
> jack demuxer 0.9 patch to work, you must activate the timefilter in
> libavformat/Makefile, by adding timefilter.o to the list of OBJS.
> 
> Michael Niedermayer wrote:
> > On Fri, Mar 06, 2009 at 12:06:23PM +0100, Olivier Guilyardi wrote:
[...]
> >> 2 - You are mesuring the jitter (or call it error). But what about the drift?
> > 
> >> What if your filtered time slowly drifts away from the system time?
> > 
> > thats part of the error, thats why iam using the error (sum of squared
> > differences between the true time and the filtered timestamps)
> > 
> > 
> >> For
> >> instance, the device clock has by definition no jitter (the cycle period is
> >> fixed) but it *always* drifts (forward or backward).
> >>
> >> Please show us some graphs based on your filter, something similar to this:
> >> http://www.samalyse.com/code/pendule/benchmarks
> > 
> > should be attached
> 
> Well, your filter seem to work ok. I've done some printf+octave debugging from
> the jack demuxer, and the jitter looks ok. According to your graphs, your filter
> doesn't drift. I'll do some more testing when I find time for this.
> 
> About the jitter graph, by "uncorrected" you mean gettimofday(),

my simulated "gettimofday()" yes
the code is in svn under #if 0/1


>  and by "fixed
> coef" the original DLL filter as Fons designed it, is this right?

almost, ive reordered operations a little which improved performance by 20%
that was done before the test and i had not undone that ...

the reason for the reorder was that the original code did not use the most
recent time sample, that is it did
update things to predict the next time but the current estmate just used the
previous information.


> If this is the
> case, then it would be useful that you only display the "fixed coef" and the
> "variable coef" plots, so that we can actually compare them visually. It's damn
> small now.
> 
> Anyway, if I find time for this, I might add your filter as an alternative to
> the original DLL filter, in libpendule. This way I'll do some more benchmarking.
> 

> If that happens, maybe that we could talk some more about it in the future. 

> Why
> don't you subscribe to linux-audio-dev then? It's a project-neutral mailing

done, but i cant promise to actually read it regularly

ill review the patch seperately ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090306/ec3c9488/attachment.pgp>