PsychoPy stops playing audio files halfway through experiment but continues otherwise

Coding
1

I’m preparing an EEG script in the coder (version 2026.2.4, Windows) in which I separately present video files (without audio) and audio files. During a testrun, I noticed that somewhere during the experiment, the audio cuts out and does not turn back on again in the next trial. The experiment does not crash or throw warnings, and the videos keep playing as if nothing is wrong.

To isolate the issue, I wrote a very small-scale test script, which only plays the audio files (so no EEG triggers, text screens, or video files). In this case, the same issue occurs. I have 32 short (approx. 3 second, 250 kB) audio files (48 kHz, mono). Each is supposed to be played in total 6 or 7 times throughout the experiment, for a total of 207 trials. I use audioLib = ‘ptb’ and audioLatencyMode = 1.

I tried both to load all sounds in advance to a library ({filename: SoundPTB object, …}), accessing as needed. Alternatively, I’ve tried loading the sound (using sound.Sound()) from the file path on each trial. I have also tried creating one sound object and changing the file using .setSound() on each trial. All these approaches result in the same problem. I’ve had one successful run I believe, showing that the problem certainly does not occur at the same time each time, or at the same file. What could be going on?

2

Some more clues: even when trying to play the same sound for 207 trials, the sound is lost after approximately 90 iterations.

I am playing the sound through an external audio interface (Arturia Minifuse 1), but that does not seem to be the issue. Other experiments in my lab have had no issues with this device.

3

Dear Floris,

Have you tried making sure you set the duration of the sound component to be a singular, that is longer than your longest sound file? I know psychopy will run into issues where setting the duration of the sound file to be the length of the sound file, or just allowing it to end after the sound file ends, has had issues similar to yours occur. Then the sound file does not “finish” properly and then sound breaks.

For more intensive debugging, I would first set the duration of the routine where the sound component is presented to be some arbitrary value that is well above your sound file lengths (e.g. 10 seconds). Run it, see what happens. Then set the sound component to be some arbitrarily large value like 6 seconds, with the routine itself still be longer. Then make sure there is routine of at least 1-2 seconds inbetween sound stimuli trials.

The other thing, is does it happen only after ~70-90 trials? Or can it happen earlier? I know you said you had a successful run, but does the issue occur within the first 10-30 trials ever?

Have you tried running the experiment using the computer’s basic audio driver, and playing through some regular speakers? I know other experiments have not had the same problem occur, but it’s always best to check all possible points of failure.

Issac

4

Hi Issac, thanks for your quick reply! I tried the things you suggested. I’m working in the Coder only, so I implemented your suggestions this way (this is the trial loop of my isolated script to play audios only).

audio = sound.Sound(filepath,
                    sampleRate = 48000,
                    stereo = False,
                    loops = 0,
                    secs = 4) # secs = 4 Added for Test 2

for x in range(207):
    core.wait(1)                 # Added for Test 3

    t = core.Clock()
    t.reset()

    audio.play()


    # while audio.isPlaying:    # Original test
    while t.getTime() < 6       # Added for Test 1
        core.wait(0.1)


    endtime = t.getTime()


    if audio.isFinished:
        print(f'{x}: finished with (t) = {endtime}')
    else:
        print(f'{x}: not finished with (t) = {endtime}')

Note that I now use only a single audio file and loop it 207 times, just to test. This file has a duration of 2.5 seconds, so I figured an audio duration of 4 and a trial duration of 6 would do the job.

I first tried to base the trial routine on a time (6 seconds) rather than on the condition isPlaying. This broke after about 140 trials. Next, I added the duration secs = 4 to the audio file. This broke after 90 or so trials. Last, I added core.wait(1) at the beginning of the loop. This broke at around 110 trials. So as you see, it’s quite random.

By the way, when I used while audio.isPlaying, the loop consistently triggered the audio.isFinished condition. Using t.getTime() the .isFinished attribute never registers as True.

Answering your last question: yes, with some permutation of testing in the past (though I can’t remember which one) I have had the thing crash as early as 5-30 trials. But almost always it makes it to at least 80-90.

5

Dear Floris,

Have you had time to test it using a different audio device? With the issue occurring (mostly) after a set number of trials, I feel like this is leaning towards a resource issue. However, running it on just the default sound card on the computer, and just normal speakers rules out any issues with Minifuse.

Issac

6

Hi Issac,

Yes this turned out to be the issue exactly. I tried to run my original script on my (pretty weak) laptop, and it ran perfectly. This morning, I tried using the lab PC’s built-in soundcard instead of the external audio device, and all was well.

For future reference: the external audio device that the lab was using is the Arturia Minifuse 1. I think in terms of audio playing latency it’s fine. But it seems that if you have many short audio files, turning the sound on and off and on etc., and if you require strict audio timing (i.e., PTB), the interface might at some point miss its cue, or otherwise can’t deliver what is required of it. (Possibly there is a solution to this, but I’m happy using the built-in sound card, so I probably won’t look into it further.)