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

[Tanu Kaskinen]

On Mon, 2013-11-11 at 21:00 +0600, Alexander E. Patrakov wrote:
> 2013/11/11 Tanu Kaskinen <tanu.kaskinen at linux.intel.com>:
> > On Sat, 2013-11-09 at 02:34 +0600, Alexander E. Patrakov wrote:
> >> 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.

If it's possible to have a resampler that is always better or as good as
anything else in speed, quality and licensing, then sure, let's drop all
other resamplers when we have that perfect resampler.

> > 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.

"Eventually" is exactly the time frame that I was thinking of. If you
want anything to ever happen in this area, you'll most likely have to do
the work yourself, which is why I asked if you have planned to do that.

-- 
Tanu