I was trying to record 'Monitor of Built-in Audio Analog Stereo' at 44.1kHz, but for some reason PulseAudio actually recorded it at 48kHz. The result is a 44.1kHz audio file that actually contains 48kHz audio, so when it is played back there is a very noticeable pitch shift and the length is also wrong. I could reproduce this with my own application (which uses ALSA), Audacity (also ALSA), arecord and parecord. For the last two I used these commands (while playing a 44.1kHz MP3 in VLC):
arecord -f S16_LE -c 2 -r 44100 /tmp/alsa-test-44100.wav
parecord --format=s16le --channels=2 --rate=44100 /tmp/pa-test-44100.wav
I also tried recording at 48kHz, and this doesn't fix the problem. The following commands:
arecord -f S16_LE -c 2 -r 48000 /tmp/alsa-test-48000.wav
parecord --format=s16le --channels=2 --rate=48000 /tmp/pa-test-48000.wav
... would also result in pitch-shifted sound.
I also tried repeatedly switching between the 'monitor' and my microphone (with pavucontrol), and there was only a pitch shift when I recorded the 'monitor'.
I tried to change some settings in daemon.conf so I restarted PulseAudio, but it turns out that just restarting made the problem go away. After that I haven't been able to reproduce it. But I'm sure it was there: I still have the pitch-shifted audio files and a list of packet timestamps from my application.
I am using Arch Linux and PulseAudio 4.0. I am using the default configuration except for 'flat-volumes=no'.
I can upload the audio files and packet timestamps if they are useful.
I've figured out how to reproduce the bug. It's related to the switching between normal and alternate sample rates. These steps will trigger the bug:
- Make sure nothing is using PulseAudio.
- Play anything at the alternate sample rate (48000 Hz) and then stop it.
- Record the monitor (at any sample rate).
- Play something (at any sample rate).
Result: The pitch of the recorded audio is too low. It appears that PulseAudio is still using the alternate sample rate, but the monitor thinks it's using the default sample rate.
The bug goes away if default-sample-rate == alternate-sample-rate.
Thanks for reporting and debugging this. I made a fix for this bug (along with several other fixes) and sent it to the mailing list: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/17919