Steep mode resampler fails

[Con Kolivas]

I've tried to enable steep mode while upsampling (2x) with SOXR_STEEP_FILTER but the music subsequently plays back at many times its normal speed. A bit of fiddling shows that once the passband_end is >98% bandwidth it starts doing this.

[robs]

I'm not seeing any problem with this here.
For example, using one of the soxr examples, with and without steep filter:

sox -r96k -n 0.f32 synth 8 sin 0:48k gain -1
./3-options-input-fn 1 2 1 0 0  4 < 0.f32 >1.f32
./3-options-input-fn 1 2 1 0 0 44 < 0.f32 >2.f32
sox -M -r192k -c1 "[12].f32" -n spectrogram -z 150 -hwk -o steep.png

All looks fine in the resultant spectrogram.

[Con Kolivas]

Not with sox directly; sox works fine, but with libsoxr only.

[robs]

In the example I gave, sox is being used only to generate, then analyze the audio. The resampling is being done by libsoxr, using one of the example programs provided with libsoxr.

[Con Kolivas]

Okay, must be me misusing it then since I'm trying to use it with pulseaudio resampling by just adding the SOXR_STEEP_FILTER flag to soxr_quality_spec() and something goes wrong and playback is scrambled at 10x speed. I don't have an issue when using just sox by itself. Thanks for your time.

[Con Kolivas]

Sorry to bring this up again, but I've tried modifying pulseaudio with sox-vhq to quality_recipe |= SOXR_STEEP_FILTER without any other changes and I just get scrambled playback (100x speed) when using sox-vhq. Is this a pulse issue?

[robs]

Hello again, I'll try to look into this sometime in the next week.

[robs]

Please can you provide details of your pulseaudio config files (and alsa if appropriate).

[Con Kolivas]

/etc/pulse/daemon.conf :

default-sample-format = s24le
resample-method = soxr-vhq
default-sample-rate = 96000
alternate-sample-rate = 88200

[Con Kolivas]

And in pulseaudio source to try and add the steep filter,
src/pulsecore/resampler/soxr.c
line 152 add:
quality_recipe |= SOXR_STEEP_FILTER;

or of course you could just hard wire the SOXR_STEEP_FILTER on in soxr code.

[robs]

I tested on Ubuntu 18.10 with your daemon settings sbove and SOXR_STEEP_FILTER forced on in the soxr code and audio played normally.
I then used the following script to capture some resampled output; the resulting spectrogram shows that all is as expected: steep filter is being applied and no distortion occurring. Please can you try the same script and report the result?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#!/bin/sh set -e sink_name=capture rate=96000 format=s24 pactl load-module module-null-sink sink_name=$sink_name sox -r 44100 -n /tmp/sweep.wav synth 8 sin 0:22050 sin 22050:0 gain -1 pad .5 .5 parec -v --rate $rate --format $format''le -d $sink_name.monitor | sox -t $format -c2 -r$rate - /tmp/recorded.wav & pid=$! PULSE_SINK=$sink_name sox -q /tmp/sweep.wav -d kill $pid; wait sox /tmp/recorded.wav -n spectrogram -wk -z150 -o /tmp/recorded.png display /tmp/recorded.png

[Con Kolivas]

I've attached a screenshot of running that script. As you can see, there is basically zero time in the frequency spectrum graph. The resultant file is only 80 bytes long compared to the original 3175280 bytes.

[Con Kolivas]

I did a little bit more poking around to see what the cut off was before this problem kicks in and the steepest I can set the filter is 1 - .02 / lsx_to_3dB(rej). As soon as I set it to 1 - .01 or steeper it starts having this problem. My guess is pulseaudio is trying to adapt to the predicted extra latency somehow and failing, but I'm no expert on pulse.

[robs]

Maybe. Though still not sure why it works for me and not for you. Perhaps due to different versions. I can try again with ubuntu 19.04 once it comes out in a couple of weeks time.