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.
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.
I've attached a screenshot of running that script. As you can see, there is basically zero time in the frequency graph.
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.
And in pulseaudio source to try and add the steep filter, src/pulsecore/resampler/soxr.c line 152 add: quality_recipe |= SOXR_STEEP_FILTER;
/etc/pulse/daemon.conf : default-sample-format = s24le resample-method = soxr-vhq default-sample-rate = 96000 alternate-sample-rate = 88200
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?
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 (10x speed) when using sox-vhq. Is this a pulse issue?