[pulseaudio-discuss] [PATCH 03/11] resampler: Change interface, resampler may return the number of leftover frames

[Alexander E. Patrakov]

2013/11/11 Tanu Kaskinen <tanu.kaskinen at linux.intel.com>:
> On Sat, 2013-11-09 at 02:34 +0600, Alexander E. Patrakov wrote:
>> Peter Meerwald wrote:
>>
>> > some resampler implementations (e.g. libsamplerate and ffmpeg) do not consume
>> > the entire input buffer; the impl_resample() function now has a return value
>> > returning the number of frames in the input buffer not processed
>> > these frames must be saved in appropriate buffer and presented together with
>> > new input data
>>
>> (yes I know this is too late, as the patch is already pushed, but...)
>>
>> First, I slightly object to the commit message. It may be
>> misinterpreted as "they don't even look at the entire input buffer".
>> While sometimes this is true (e.g. because the output buffer size was
>> a limiting factor), there is another important reason why some samples
>> need to be presented again. Namely, this happens if they affect both
>> the old and the new chunk of output data and the resampler
>> implementation relies on the user to housekeep the input buffers.
>>
>> Second, I consider all resamplers that don't do this (i.e. that handle
>> the necessary buffering internally in an opaque manner) as
>> fundamentally broken if rewinds are allowed, and would argue for their
>> refactoring or deletion. And here is why (yes, I am a perfectionist in
>> the bad sense of this word).
>
> Outright deletion is an option only if we think that the deleted
> resampler is worthless or nearly worthless to us. Imperfect rewind
> handling alone doesn't make a resampler worthless.

You are right - by itself, clicky rewind handling does not negate
other benefits of a resampler. The ultimate long-term plan should be,
however, to either have one perfect resampler instead of the current
choice that looks quite similar to the situation that GNOME had with
clocks (even if that would mean writing it from scratch - but I doubt
that), or to have a document that clearly explains why a tradeoff is
necessary without invoking historical and legal reasons.

> I don't understand why making e.g. the ffmpeg resampler handle rewinds
> correctly would necessitate the deletion of all resamplers that don't
> handle rewinds correctly. That oddity notwithstanding, it sounds like
> you have a solid plan for fixing the rewinds at least for a subset of
> our resamplers, so can we expect patches coming at some point?

As far as I understand, ffmpeg resampler is very small (and thus easy
to understand), fast, stateless (which means easy support for
rewinds), suitably licensed, and already copied into PulseAudio code
base (which means that we can improve it further without prior
coordination with upstream). When one adds variable sample rate
support, it would become _the_ perfect resampler. By itself, this
doesn't mean that everything else should be deleted, but the less
things to abstract, the better.

I don't think you can realistically expect patches, though, in a short
timeframe - but eventually I would really like to do that. I still
have the IIR-based module-virtual-surround rewrite sitting on my
laptop's SSD, waiting for a releasable and well-commented
coefficient-generation script :(

-- 
Alexander E. Patrakov