sounddevice.play vs manual OutputStream - samplerate confusion
See original GitHub issueWhen I use the convenience function play
to play a wav file at a particular samplerate, it seems to play back at the correct rate.
However, when I attempt to play the same wav file by manually creating an OutputStream with the same samplerate, the sample seems to play back at far too high a rate.
To the best of my knowledge, I set things up correctly, but I’m wondering if I’m missing something obvious. I’d appreciate some advice if so. Below are some details - pardon me if I’ve left anything important out, I can update this (such as with a link to the sound file itself) if needed.
Platform/API: macOS/Core Audio
Audio device: Scarlett 4i4 USB (6 in, 4 out) (device 3 according to query_devices()
)
Python module versions:
% python3 -m pip show sounddevice
Name: sounddevice
Version: 0.4.2 ...
% python3 -m pip show soundfile
Name: SoundFile
Version: 0.10.3.post1 ...
The minimal(ish) script that reproduces this on my system:
import sounddevice
import soundfile
data_type = "int16"
file = soundfile.read("samples/misc_crow.wav", dtype=data_type)
data, sample_rate = file # sample_rate is 44100
sounddevice.play(data, sample_rate, device=3) # sounds fine
sounddevice.wait()
output = sounddevice.OutputStream(device=3, dtype=data_type, samplerate=sample_rate)
output.start()
output.write(data) # sounds much too fast/high pitched
output.close()
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (3 by maintainers)
Top GitHub Comments
Thanks for testing! I’ve just merged #372. If there’s anything else not working, please let me know!
No, you might have found a bug.
Is your file a mono file?
It looks like when
data
is one-dimensional, theStream.write()
function doesn’t check whether the stream has one channel.In your case, the stream has 4 channels, so the audio data is distributed over 4 channels, each one being four times faster (i.e. two octaves higher) than intended (and probably having some aliasing artifacts).
So I think this is a bug.
As a work-around, you can use
channels=1
when creating theOutputStream
.