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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
