Sound Missing on Random Trials, No Error Code

Hi there,

I have an experiment with eight tasks. Four of the tasks involve two disks colliding with each other while a sound plays at varying times respective to when the disks meet (e.g. 200ms before, 133ms after, etc.). There are 13 conditions, with each condition repeated 5 times (coded via Excel).
The sound is a “sound.wav” file that plays correctly, but for some reason it is silent on random trials (~8 in every 60 trials). I say silent because in my data file, the times that the “silent” sounds started and stopped are still being recorded. I also get no error code. Sounds in other tasks that don’t involve the disks play fine in every trial.

I’ve tried changing audio libraries, deleting “sounds” from self.sounds.random, and for hours I’ve scoured differences between the code in tasks that work and the code in these tasks with the moving disks. No luck.

The sound is coded as sound_1=sound.Sound(’…/stim/sound.wav’)

set up handler to look after randomisation of conditions etc.

#set up handler to look after randomisation of conditions etc
trials = data.TrialHandler(nReps=5, method='random',
    extraInfo=expInfo, originPath=-1, seed=None, name='trials', 
    trialList=data.importConditions('Conditions_Task3.xlsx'))
thisExp.addLoop(trials)  # add the loop to the experiment
thisTrial = trials.trialList[0]  # so we can initialise stimuli with some values
# abbreviate parameter names if possible (e.g. rgb = thisTrial.rgb)
if thisTrial != None:
    for paramName in thisTrial:
        exec('{} = thisTrial[paramName]'.format(paramName))

for thisTrial in trials:
    currentLoop = trials
    # abbreviate parameter names if possible (e.g. rgb = thisTrial.rgb)
    if thisTrial != None:
        for paramName in thisTrial:
            #exec('{} = thisTrial[paramName]'.format(paramName))
            exec('{} = thisTrial[paramName]'.format(paramName), locals(), globals())

start/stop sound_1

        #start/stop sound_1
        if frameN == (midPoint + round(delay*60)) and sound_1.status == NOT_STARTED:
            # keep track of start time/frame for later
            sound_1.tStart = t  # not accounting for scr refresh
            sound_1.frameNStart = frameN  # exact frame index
            poly1SoundPos = polygon.pos
            poly2SoundPos = polygon_2.pos
            win.timeOnFlip(sound_1, 'tStartRefresh')  # time at next scr refresh
            win.callOnFlip(sound_1.play)  # screen flip
        if frameN >= (midPoint + round(delay*60) + (soundT*10)) and sound_1.status == STARTED:
            win.timeOnFlip(sound_1, 'tStopRefresh')  # time at next scr refresh
            win.callOnFlip(sound_1.stop)  # screen flip

As far as I can tell that’s the most relevant piece of code. Delay refers to sound delay (i.e. a trial) and midpoint is when the disks meet, defined as midPoint = int((len(poly1Pos)-1)/2)

I’m very new to Psychopy and don’t know Python, although it is intuitive. But the experiment I have was developed by someone else who is currently away and I need this fixed asap. Given my lack of knowledge I understand if this question is unanswerable. I can provide additional information if needed (especially more code). Thanks very much, I’m at my wits end with this.

I’m on Windows 10, using Coder, and on PsychoPy v3.1.0 with no customisation. I briefly tried using PsychoPy 3.2 with it but nothing changed.

Update: I seem to have fixed the issue (knock on wood). Updating to the latest version of Psychopy (3.2.2) and using the new PTB audio library seems to have done the trick. When I tried the update before I failed to realise that there was a new audio library.
Pretty crazy I had this profound issue, as surely so many other people would have had the same problem as me if it really was a problem with the older audio libraries.
Given that my sounds with the PTB library seem marginally more accurate (hard to tell though haha, could very well just be bias), I’m thinking maybe it was an issue with an imperceptible amount of lag that would occasionally cause my code to fail to pick up the start of the sound. Anyway, I have no idea but I’m just glad that my issue seems to be fixed.