Sounddevice issue with stream started at beginning

Hi all,

I’m having an issue with intermittent problems with sounddevice. A majority of the time I call it (see the minimal example below), I get a horrible sound that plays continuously. It starts as soon as line 151 of backend_sounddevice.py is called:

self._sdStream.start()

I imagine it has to do with starting the stream at the beginning of the experiment, as mentioned in this thread. This is further supported by “test.play()” working, but only creating a tone on-top-of the noise.

Stranger, this error doesn’t happen every time. Sometimes I run the code below and it is perfectly silent until I run “test.play()”, which results in a simple tone, as it should. Occasionally an error is printed out (but not every time)

invalid value encountered in multiply toSpk *= 0 # it starts with the contents of the buffer before

Minimal example

from psychopy import prefs
prefs.general['audioLib'] = ['sounddevice']
from psychopy import visual, core, event, sound
test = sound.Sound()

Relevant environment details:
Ubuntu 16.04
Python 2.7.12
Psychopy: 1.85.3
sounddevice: 0.3.9

Thanks for any help!

No one else experiences this? I’ve noticed it on OSX as well, so it seems more general than just an ubuntu issue.

Hi Ian,

Just trying out the sounddevice backend, and I have the same problem (very annoying/loud buzzing tone sound as soon as I define a sound, which presumably is starting the stream). Did you manage to find a solution? Hoping to avoid Psychopy v1.90 until it’s got the bugs worked out, but this issue is not tolerable.

I think I had something similar when using pyo that was solved by specifying prefs.general['audioDriver'] = [u'jack'], but sounddevice uses portaudio, which is already the default driver…

I have the exact same system specs (OS, python, psychopy, sounddevice).

Thanks!
Colin

I’ve been looking into this issue with the help of @matthias.geier, and we have a few leads that indicate there is likely a bug in the pyschopy implementation of sounddevice. Please see below for the relevant details of our troubleshooting exchange and this google drive folder for audio files with examples of the problem (discourse won’t upload audio files). @jon, do you have any suggestions for how to proceed?

After verifying sounddevice itself works fine (e.g., play_file.py from the github page on the same new_loss_sound.wav file), the suspected culprit was under-/overruns. We manipulated the block size, and found that the frequency of the buzzing was inversely related to the block size (i.e., higher pitches for smaller block sizes, with large block sizes leading to low clicking sounds). Interestingly, the buzzing is not there if block_size=128 or block_size=256 in some random cases, but it is stochastic and changes from run to run with no apparent consistency. (Note the block_size=256 version attached turned out clean in that particular case.)

Here is @matthias.geier’s take:

It sounds very much as if there is some kind of disturbance/glitch/discontinuity in each audio block. … It may be one or more samples with a zero value (if the rest of the values in the block are non-zero), or it may be some constant value or some random values. It might also be an unintentional repetition of some previously played values.

I’ve attached recordings of the buzzing at various block sizes (labeled in the title), as well as the .wav file supposed to be played. Here is the minimal code needed to reproduce the problem on the system listed above:

from psychopy import prefs
prefs.general['audioLib'] = ['sounddevice']
from psychopy import sound, core

block_sz = 256 #128, 256, 512, 1024, 2048
win_sound = sound.Sound(value='new_loss_sound.wav', sampleRate=44100, blockSize=block_sz, secs=0.8, stereo=True)
core.wait(1)

for i in range(3):
    print i
    if i==1:
        win_sound.play()
    core.wait(1)
1 Like

OK, I had a closer look. It turns out that the way how the output buffer is supposed to be filled with zeros is buggy: https://github.com/psychopy/psychopy/pull/1847.

2 Likes

Awesome! Thanks for figuring this out

Huzzah! Thanks very much for figuring this out! Much appreciated.