Re: new module module-plugin-sink

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



пн, 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.

-- 
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux