[pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Peter Meerwald]

Hi,

> > These patches add support for libsoxr resampler library to PulseAudio. The
> resampler is exposed in four selectable quality presets: lq, mq, hq and vhq
> (in the order of increasing quality). The patches update the code, build
> system and docs.
> >
> > libsoxr[1] is a resampler library extracted from the SoX utility[2]. It
> offers very good output quality and is very fast. Quality comparisons are
> available here:
> >
> > - http://src.infinitewave.ca/ - "SoX 14.4 High Quality" corresponds to hq
> quality. "SoX 14.4 VHQ Linear Phase" is close to vhq, the passband for vhq is
> slightly lower.
> > - http://sox.sourceforge.net/SoX/Resampling - there are graphs for impulse
> response comparison with libsamplerate available at the bottom of the page.
> > - http://lastique.github.io/src_test/ - I ran some more tests to compare
> with Speex resampler at different levels. Some performance measurments are
> also present at the end.

should have checked your evaluation before, impressive amount of work!

so the claim is soxr looks good for these "odd" rate conversions: 44.1kHz 
-> 8000*N (for useful values of N)

> > In short, libsoxr is almost always faster than speex, and introduces much
> less distortions. Its passband frequency is slightly lower than speex though,
> and it can add a delay up to 20 ms in some cases.
> 
> We generally don't need a zoo of resamplers. But you have definitely 
> changed something important from an earlier submission by Peter Meerwald 
> so that the CPU figure became much better. I guess, that's 
> SOXR_LINEAR_PHASE - that's the only obvious change.
> 
> Here are the facts, applicable to 44100 -> 48000 Hz resampling, as 
> required by some sound cards when playing back CD rips:
> 
>   * Speex-float-5 never introduces audible distortions, even on 
> specifically-crafted testcases at insane volume in an otherwise 
> absolutely quiet room. So "even better quality" never makes sense - 
> unless we are talking about non-human listeners.
>   * Speex-float-1 (the current default) does not introduce audible 
> distortions on music that you can buy in shops (or download), but does 
> create audible artifacts on specially prepared test cases.
>   * SOXR, even at its LQ setting (which, according to prior tests, is 
> good enough) and with THIS set of patches, is indeed slightly faster 
> than speex-float-1.
> 
> Statements about distortion audibility are based on the model described 
> in this scientific paper:
> 
> http://www.mp3-tech.org/programmer/docs/6_Heusdens.pdf
> 
> Distortions caused by removal of high frequencies, as well as any other 
> distortions, would have been counted as audible if a person could detect 
> that in an ABX test. The nuance here (with "auditory masking" as its 
> scientific name) is that the ear becomes less sensitive to very high 
> frequencies when there is something else in the air - and in typical 
> music, this "something else" definitely exists in a sufficient quantity.
> 
> Statement about speed is based on a direct CPU usage measurement by "top 
> -d 10" on this CPU (forced to run at 933 MHz):
> 
> Intel(R) Core(TM) i3 CPU       M 370  @ 2.40GHz
> 
> Baseline (48 kHz playback without resampling): 0.7% (0.1% on null sink)
> Speex-float-5 (44100 -> 48000 Hz): 5.6% (4.5% on null sink)
> Speex-float-3 (44100 -> 48000 Hz): 4.3% (3.1% on null sink)
> Speex-float-1 (44100 -> 48000 Hz): 2.5% (1.9% on null sink)
> Soxr-hq (44100 -> 48000 Hz): 2.4-3.3% (1.6% on null sink)
> Soxr-mq (44100 -> 48000 Hz): 2.5-3.1% (1.5% on null sink)
> Soxr-lq (44100 -> 48000 Hz): 2.1-3.4% (1.7% on null sink)
> 
> One obvious thing here is that, while Speex-based resamplers yield 
> stable performance on a real hardware sound card, Soxr CPU usage 
> oscillates rather significantly. This effect does not exist on a null 
> sink. Also, higher quality does not mean higher CPU usage, which is strange.
> 
> I will recheck the quality separately later today, in order to verify 
> that it is still as good as in the previous tests. Please don't merge 
> the patches until this is done.
> 
> 

-- 

Peter Meerwald
+43-664-2444418 (mobile)