[FFmpeg-devel] Incorrect usage of timefilter by alsa-audio-dec?
nicolas.george at normalesup.org
Thu Dec 22 20:16:38 CET 2011
Le duodi 2 nivôse, an CCXX, Andreas U. Trottmann a écrit :
> Now, the "obviously wrong" feedback2_factor is set using
> ff_timefilter_new in line 90 of libavdevice/alsa-audio-dec.c,
> in the function audio_read_header:
> o = 2 * M_PI * s->period_size / s->sample_rate * 1.5; // bandwidth: 1.5Hz
> s->timefilter = ff_timefilter_new(1000000.0 / s->sample_rate,
> sqrt(2 * o), o * o);
> In my case, s->period_size is 8192, s->sample_rate is 48000,
> giving an o of approximately 1.6 and sqrt(2*o) of about 1.8,
> which then becomes feedback2_factor in the timefilter.
> This is what I have found out so far.
> In order to get a working system, I blindly changed "sqrt(2 * o)"
> to "1.0/sqrt(2 * o)" which gives a feedback2_factor < 1, and
> causes the timefilter correction algorithm to converge rather
> than diverge. This, in turn, appears to have made me an
> ffmpeg which can encode using "-async" again. Very obviouly I
> have no idea whether that "fix" will work for everyone, or just
> for my situation.
> I would be extremely happy if someone with more insight in the
> algorithm and the parameters of timefilter could take a look at
> this, and find out how the calculation of o and the
> initialisation of the timefilter parameters in alsa-audio-dec.c
> can be properly fixed.
I can reproduce the problem. Unfortunately, I do not understand the workings
of the timefilter algorithm: I copied what Olivier Guilyardi wrote for JACK.
I will try to look into it more closely.
In the meantime, you can work around the problem by using a lower
period_size: for the box I am currently on, the period is 64 for "hw" and
1024 for "dsnoop"; 8192 is rather big.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel