[pulseaudio-discuss] new module module-plugin-sink

[Georg Chini]

On 20.05.19 13:32, Alexander E. Patrakov wrote:
> пн, 20 мая 2019 г. в 15:35, Georg Chini <georg at chini.tk>:
>> On 20.05.19 10:47, Alexander E. Patrakov wrote:
>>> пн, 20 мая 2019 г. в 13:17, Georg Chini <georg at chini.tk>:
>>>> Hi Alexander, Tanu,
>>>>
>>>> would it make sense to give filters some old data for preconditioning when
>>>> the filter should be rewound? Then the filter could simply be reset and the
>>>> preconditioning data run through the filter instead of doing a "real"
>>>> rewind.
>>>> The amount of data needed for preconditioning could be made configurable.
>>> The problem is that for IIR filter the needed amount of data is
>>> infinite. So - no.
>> That's only true in theory. In practice, you never have an IIR filter
>> because you do not have infinite resolution. And in practice, it will
>> probably be sufficient to precondition the filter in many cases.
>> Surely the result will not be perfect, but may be good enough to
>> avoid audible artifacts.
>>
>> But if you think it does not make sense, I'll leave it as it is.
> In theory, you are right, except for a slowly-recovering automatic
> digital gain control filter (similar to the analog filters found in
> tape recorders from late 80s - they take about 30-60 seconds to adapt
> to unusually quiet sounds, and that still was a useful filter, not
> "chewing" the sounds exactly because of such slow recovery).
>
> In practice, I am also strongly against supporting any form of
> rewinds, for the following reasons (I admit that I am overly harsh
> here).
>
> 1. There is already some code, in the form of the LFE filter, that
> implements some filtering logic. Making it rewind-aware took 4 review
> iterations (which is too many), and there was a "how do I test"
> question.
> 2. Look at alsa-lib code. ALSA API supports rewinds. There is a lot of
> code that is supposed to handle rewinds. However, nothing works even
> in the "dmix" plugin which is not doing any history-related
> processing.
> 3. There was a submission of xrdp sink. It also had some (meaningless,
> because you can't unsend a packet) code written for rewind handling,
> and it was obviously not tested.
>
> To be fair, in the case (3) there was no good documentation what a
> sink should do, but case (2) comes from ALSA developers, so "appeal to
> authority" argument does apply here.
>
> In other words, I don't trust random people to write the rewind
> related code correctly (in fact, at this moment, I only trust David
> Henningsson), and I don't trust them even more to test it. In some
> sense, rewind-related code is similar to error handling: hard to get
> right and hard to test. And hard to fix (many people looked at the
> current situation with monitor sources, but they are still broken if
> there are rewinds). My personal opinion - we should not add such code
> to PulseAudio, and maybe even remove support except for the very easy
> cases.
>
Well, regarding the difficulty to debug/write rewinding stuff,
I agree with you. Current pulseaudio master still has at least
one bug which makes it impossible to properly disable rewinding
and another which can lead to too much rewinding during moves.
Also I really had a hard time limiting rewinding for virtual sinks
properly and at least the speex resampler doesn't support
rewinding.

But I do not see why this should prevent us from using rewinding.
I think the statement that it should be avoided because it is hard
to get right is the wrong kind of argument. And current PA code
relies on it, for example you can lose up to one latency of audio
during a sink input move if rewinding is disabled, which is very
audible, even if the latency is limited to 50ms.