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