On 20.05.19 13:32, Alexander E. Patrakov wrote:
пн, 20 мая 2019 г. в 15:35, Georg Chini <georg@xxxxxxxx>:
On 20.05.19 10:47, Alexander E. Patrakov wrote:
пн, 20 мая 2019 г. в 13:17, Georg Chini <georg@xxxxxxxx>:
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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
