[pulseaudio-discuss] New Module: module-lfe-lp

[Alexander E. Patrakov]

2013/3/21 Tanu Kaskinen <tanuk at iki.fi>:
> On Wed, 2013-03-20 at 17:50 +0600, Alexander E. Patrakov wrote:
>> Tanu: I am still waiting for your reply regarding the best way to do
>> clickless rewinds in IIR filters (i.e. one of: "disallow rewinds",
>> "keep full history of the intermediate state", or some creative
>> solution).
>
> Oh, I didn't realize that a reply was needed. Your description of the
> problem and the suggested solutions were pretty spot on.
>
> Keeping a full history of the internal state would be the best solution,
> as far as I can see. "Full" means
> pa_memblockq_get_maxrewind(u->memblockq). Changes to the maxrewind value
> can be caught in sink_input_update_max_rewind_cb().

Is it guaranteed that, after a sink_input_update_max_rewind_cb() that
communicates pulseaudio's decision to increase max_rewind, pulseaudio
will not actually attempt to rewind that much until the filter has a
chance to accumulate that much history?

E.g. consider this example (all the numbers are made up):

0. Initial state: max_rewind is 48000 samples, the filter has that much history.
1. Pulseaudio decides that it wants to increase max_rewind to 96000
samples and calls sink_input_update_max_rewind_cb().
2. The filter resizes its internal history buffer accordingly, copies
the old history to the end of the new buffer.
3. Pulseaudio plays 24000 samples and passes 24000 samples through the
filter. Now the filter has 24000 invalid samples in the beginning of
its history buffer and 72000 samples of valid history at the end.
4. Is it guaranteed at this point that pulseaudio will not attempt to
rewind more than 72000 samples?

> Disallowing rewinds would probably be easier to implement, but it can
> cause unacceptable latency for volume changes etc.

That's true.

-- 
Alexander E. Patrakov