[pulseaudio-discuss] [PATCH 2/3] resampler: Add optional soxr resampler

[Tanu Kaskinen]

On Mon, 2014-08-25 at 01:20 +0600, Alexander E. Patrakov wrote:
> 24.08.2014 23:55, Peter Meerwald wrote:
> >
> >> 04.08.2014 18:40, Peter Meerwald wrote:
> >>> +    quality_spec = soxr_quality_spec(SOXR_QQ, 0);
> >>
> >> SOXR_QQ means "quick cubic interpolation" - i.e. the worst quality level
> >> provided by the library. It is worse than speex-float-1 (but the message with
> >> the relevant plots exceeded the maximum tolerable size for the list). I think
> >> that it makes sense to expose other quality settings provided in soxr.h.
> >
> > probably we need to let the user decide, but default to some reasonable
> > quality
> 
> Yes, even SOXR_LQ would be good enough for the definition of "good" that 
> doesn't take limited bandwidth into account. However, I would like to 
> raise one peculiar property of soxr that needs to be discussed further.
> 
> As described in the README, the soxr resampler is FFT-based (unlike, 
> e.g., libsamplerate, ffmpeg and speex). Therefore, it introduces more 
> latency than traditional resamplers - 20ms for the HQ variant vs less 
> than 1ms for a traditional resampler. Should PulseAudio be aware of it? 
> How can we make it aware?

Yes, I think 20 ms is big enough latency that we should include it in
the latency reports. It doesn't sound like a terribly difficult thing to
add latency querying to the pa_resampler interface and using that when
we need to report the latency. However, when a new stream appears that
says "I want 55 ms latency", it may be a bit complicated to take the
resampler latency into account when calculating the buffering parameters
(not that the concept itself is complex, but I find the current buffer
parameter calculation code pretty scary)...

-- 
Tanu