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

[Alexander E. Patrakov]

12.11.2014 15:59, Andrey Semashev wrote:
> On Wed, Nov 12, 2014 at 12:26 PM, Alexander E. Patrakov
> <patrakov at gmail.com> wrote:
>>
>> 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.
>
> SOXR_LINEAR_PHASE is 0, I added it mostly for documentation purpose,
> in case if someone wants to add more modes with different phase
> response presets. There is also another difference in that I
> explicitly specify interleaved sample formats, although it is
> numerically equivalent to those without the _I suffix.
>
> I think, the essential difference is quality. Peter's patches use
> SOXR_QQ, while mine use other presets. I didn't add QQ because I don't
> see much point in this mode.

Indeed, QQ is just cubic interpolation, worse than speex-float-0. 
However, I have tried to change that to other values in the old patches, 
and the result was a good resampler that ate a lot more CPU than 
speex-float-5. Note, however, that the test was done with a Haswell 
(year 2013) earlier and with an Arrandale (year 2010) now.

>
> I also noticed unusual relation between quality and CPU consumption.
> You can see that in my results LQ actually appears the most consuming
> in some cases. I don't have a good explanation for this, my guess is
> that this could be related to different math precision and
> optimization. I think the library uses different precision for math on
> different quality levels (i.e. double in VHQ, float in HQ, etc.), and
> it does have some optimizations for SSE. It's possible that LQ path is
> not as optimized. One would probably have to inspect libsoxr code to
> tell for sure.
>
>> 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.
>
> Thanks for the reference and all the information.
>
> I didn't do a blind test to detect the audible difference, all I can
> say is my own impressions. I have a locally patched PulseAudio 4.0 and
> I'm using soxr-vhq preset resampling everything to 96kHz (I have
> records in 96kHz that I don't want to resample). The difference with
> speex-float-5, which I used previously, is indeed rather subtle. I'd
> say, the sound is a bit more clear, instrument separation is better,
> especially in bass. But that's all subjective, of course, so it should
> be taken with a big grain of salt. In any case, soxr-vhq is clearly
> faster than speex-float-5, so at the very least it's a performance
> improvement for me.
>
>> 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.
>
> Thanks, I'd be interested in the results.

Will do that after reviewing two work-related (non-audio) patchsets.

-- 
Alexander E. Patrakov