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
