Truncated audio frequency response on snd-aloop device (resample-method = speex-float-1, default-sample-rate = 48000)
Playing a chirp like generated sound in stereo (same chirp both in channels, the chirp is originally a mono track) and recording it through the Built-in audio monitor drops frequencies over 16kHz both when recording in stereo at 44100 sample rate and when on 48kHz . (Currently I've confirmed it happens when the sample rate is whatever but 44100, even in 88200!!) Also, in some cases I found it to have phase shift between stereo channels causing a comb filter like frequency response on the mono mix. (That is if you record it in stereo, then sum up both channels to a mono track)
This is the original chirp sound:
This is a part of the recorded loopback sound showing the issue: chirp_loopback_recorded.flac
Steps to reproduce ( SPEAKER / HEADPHONE WARNING!!!!!, turn the volume down )
Any player will do it, but if you have a stock installation you can get all these tools issuing:
$ sudo apt install pavucontrol ffmpeg audacity
Then edit /etc/pulse/daemon.conf and add these lines:
- resample-method = speex-float-1
- default-sample-format = s24le
- default-sample-rate = 48000
Restart the pulseaudio daemon.
I played it on the command line with:
$ ffplay -loop 1000 chirp_test.flac
Then I setup the recording path with pavucontrol, to target the Audacity input
What is the current bug behavior?
Something is happening on the audio chain causing either to
one channel of the stereo change in phase with respect to the another or ..
there is some resampling issue?
What is the expected correct behavior?
Recording from a virtual loopback device is expected to have a flat frequency response between 0 to Fs/2, but there is an unexpected amplitude drop for 16kHz and up, like there is a low pass filter.
Also reported here: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1882587
Edit: I noticed the vu-meter bar on pavucontrol to drop and peak unexpectedly near these frequencies. I double checked there is no pulseffects applied on the chain.
Spectrum plots of the recorded signal in Audacity shows even more confusing results which seems to vary somewhat with sampling rate. I'm little lost here. I found it while experimenting with gnu radio and DSP style programming.
Edit2: I installed a fresh ubuntu bionic, and tested it, without the modifications in /etc/pulse/daemon.conf it works just fine, but if it is forced to resample, it fails.
Edit3: This test will show unexpected behaviours on all speex-float-N methods, it unexpectedly peaks when the audio repeats. src-linear, src-sinc (all versions), src-zero-order-hold and ffmpeg shows similar behaviours.
It only passes with the trivial one.