Sound components cut short

URL of experiment:

Description of the problem:

Sounds are sometimes cut off. They appear to play fine during the first loop (“trials”) but the same audio files are cut short during the three later loops (“trials_2, 3, and 4”). I have tried adding code component to Every Frame:

//if (t > (dingsound_2.getDuration() + dingsound_2.tStart+1.5)) {
// dingsound_2.stop();
// dingsound_2.status = PsychoJS.Status.FINISHED

I have tried adding code component to End Routine:


Both of these were solutions I found in the forum reported by people who have similar issues. Thoughts?

I also tried changing the audio library to pygame as suggested in other threads, but that did not work either!

While this was a builder-specific problem for me, it seems it appears in online tests as well. The first sound you play in your loop simply sets the time limit for all other audio files played within that loop. In other words, if the first audio file is 3500ms long, all subsequent audio files, regardless of their original duration, will be cut at the 3500ms point. The way I addressed this was by making sure that the longest audio file is always the first in the loop. Hope this helps!

Thanks for your reply! In my case the order of the stimuli is pretty important so it doesn’t make much sense for the longest one to come first. Allowing different sound component durations in a loop seems pretty reasonable so I hope there’s some workaround.

Actually there’s another sound component within the loops that represents the test stimuli, and it’s important that that is fully randomized. Now I’m a little concerned that perhaps the same issue is happening there (the later audio are cut short if they were longer than the first trial), but it would be harder to tell since they are excerpts and if they cut off early it’s not very obvious.

Hi @pavle, I was thinking based on your response perhaps I could go into the .js and alter that part of the code, but I don’t see anything in the .js that might set a time limit for that component. Do you recall what that line of code might look like?

Hi @HEKragness, I was under the impression that at least on desktop the matter had been addressed. Would you mind giving me access to your repo? Thanks for flagging, x

I’m actually running online, sorry if I wasn’t clear about that. I’ve granted access in any case.

Alright, cool, thanks, x

Hi @HEKragness!
I’ve tried setting the duration on every repeat, but that didn’t fix the problem for me. But I have to say, that was 3 months ago and things could be looking different now with the latest updates. I also need my stimuli randomised so what I do is I shuffle the list of stimuli and then find the longest audio and put it as a fist element in the list. That way everything is randomised except for the first file (obviously my experiment allows for this). If this isn’t a viable option for you, I would try playing with sound.reset() and/or setting the sound.status to NOT_STARTED manually, maybe in the ‘end routine’ tab.

Q: How many different audio files you have in your experiment? Is it a few or much more?

Thanks for your response @pavle! I have 16 test files, but they are split into 4 loops of 4 iterations with breaks in between each loop (testing kids). The order is fully randomized so any stimulus could appear in any block or order. I guess using your method would mean that even if I randomized which files were in which block, some files would be much more likely to occur first in the block than others. Given the rather short attention span of my participants (kids) I think it’s pretty important for the order within each block to be totally randomized so that some kids get each stimulus first. :confused:

If this isn’t a viable option for you, I would try playing with sound.reset() and/or setting the sound.status to NOT_STARTED manually, maybe in the ‘end routine’ tab.

Thanks! I will try this.

Okay, since you don’t have hundreds of audio files (like I do :smiley: ), you could have 4 sound components in each loop. I think that would sort this out as each sound component would only get one audio file played. And you can make it so that sound components are always played in the same order, but you shuffle the sound value in a code component, or you can make each sound component always play the same audio file, only components start randomly. I haven’t tried this myself, but it seems it could work. Let me know if it does.

Wow, that would probably work. I’ll try it!

On second thought… the onset of ANOTHER sound component and the mouse component are both conditional on the end of this looped component, so while I think adding the components would fix the cut-off issue, it would create new issues with the timing of those subsequent conditionals…

Any ideas? I’ve hit a bit of a brick wall with my own problem-solving as well as some others proposed below… Also, after granting member access yesterday none of my changes seem to be reflected on gitlab anymore (although Psychopy registers a “successful sync”)?

Hi @HEKragness, such a sweet looking project, sorry I only mentioned the desktop because you said you tried switching to pygame for which there is no online equivalent. As a first step to debugging the problem, I have staged a fork in pilot mode below based on PsychoPy latest. My worry initially had been that as the sound value gets updated on each trial, PsychoJS was struggling to recalculate the duration property, but that seems to not be the case. Would it be OK if I asked you to give me a specific sound that is being cut off? Is it always the sounds past the first one? Are these the “music” component sounds? Thank you, s.

Haha thanks. We gotta get creative for kid experiments, haha. The pygame thing makes sense, I saw that as a solution on other forum questions but I didn’t realize it was desktop-specific.

I have been fiddling with other possible solutions but the dingsound_3 and dingsound_4 components (which are in trials_3 and trials_4 loops) very often get cut off. It’s easy to tell because the sound is a sentence and it doesn’t reach the end of the sentence. dingsound in trials, on the other hand, never gets cut off. dingsound_2 often does as well but I’ve been fiddling with that loop to try out the other possible solutions I mentioned.

I’m worried the music might also be getting cut off but it’s harder to tell than the sentences, for which it’s obvious. I’d like to check by comparing the audio file duration against time on/off for the music components, but despite having “Save onset/offset times” checked under the “Data” tab I don’t actually see it in the output anywhere.

Alright, thanks, I think I understand a little better now :blush: But is the 2020.2.10 generated fork also problematic in the same way? Is it by design that sometimes the message about the no coin animal will repeat in the background after answering what the animal position was? x

Sorry if this is naive but I thought I could only test from the master branch? I’m not sure where or how to test a version in a branch.

Is it by design that sometimes the message about the no coin animal will repeat in the background after answering what the animal position was?

Definitely should not happen, and this has never happened while I was testing it!

No worries, are you able to pilot this one?