Letting audio play through after choice response

[sten_knutsen]

In our current setup, the audio stimuli are set with barrier: true, so the choice response is only available after the audio finishes playing.

If I change the audio stimuli to barrier: false, the choice response becomes available as soon as the audio starts, but selecting a response causes the audio to stop.

Is there a way to set barrier: false so that participants can make their choice while allowing the audio to continue playing until the end?

-- sten

[noah.nelson]

In our current setup, the audio stimuli are set with barrier: true, so the choice response is only available after the audio finishes playing.

If I change the audio stimuli to barrier: false, the choice response becomes available as soon as the audio starts, but selecting a response causes the audio to stop.

Is there a way to set barrier: false so that participants can make their choice while allowing the audio to continue playing until the end?

-- sten

Hi Sten!

This is interesting, thanks for the question! As a general rule, we treat "active" response types, such as the choice response, as a trigger for the end of the trial. This is the first request we've received where that behavior is not actually desired.

We have been engaging in some minor tweaks to how the ends of trials get triggered. It is possible we might be able to incorporate something that can address this issue, but we will need to investigate a bit first. Do you have a timeline for when you would need a solution for your study?

Thanks as always for using FindingFive!
 -- Noah

[Ting]

Hi Sten,

I think you'll run the risk of collecting more data you want (and a disclosure issue as well), but here's a way to hack it:

1. Include a background audio response to collect audio recording (which you should tell your participants).
2. Set its duration as relative to the audio stimulus (https://docs.findingfive.com/en/designs/...e-duration) by something like half a second (or maybe +0 could even work)
3. Add both the audio response and the choice response to the trial.

That way, the trial should behave like what you described. The core principle here is that you'll need some other response that has a "duration" parameter to prevent the trial from ending too early. The relative duration is the only trick I can think of though.

Ting

[Ting]

Hmm...now that I've described the hack, I guess the solution we can implement on our end is to introduce a "dummy" response that has a duration then! Hmm...

[sten_knutsen]

Hi Ting and Noah,

Thanks for the suggestions! It seems like the hack works — I’m getting the behavior I want — though I did things a little differently than what Ting described:

• I set the audio stimuli to barrier:false and delay:2. We’ve been using this delay because we want participants to see the image stimuli first (no delay) before hearing the audio stimuli.
  
• I set the choice responses to delay:2, so the choice buttons appear at the same time as the audio starts playing.
  
• I created a new “background audio” response with delay:0.
  
• This setup seems to give us the behavior we want. Just to clarify, we want participants to make their selection in "real time" or as "online" as possible. However, we don’t want them to learn that they can quickly skip through the study by pressing a button to advance before the audio finishes playing.
  

The only thing I don’t fully understand is why this setup works the way it does. I noticed that if I set the choice responses to delay:0, the choice buttons appear simultaneously with the image (before the audio). At that point, participants can click a button and advance to the next trial before even hearing the audio — which is not the desired behavior. So, by setting delay:2 for the choice responses (to match the onset of the audio), the issue seems resolved.

My question is: will the choice response still capture reaction times accurately — specifically, from the moment the buttons appear to when the participant makes their selection? Additionally, how is the trial's offset triggered after the choice response is made?

Thanks again for your help!

— sten

[Ting]

Hi Sten,

Glad you found a hack! The confusing part you pointed out is indeed confusing. My reasoning would have predicted a different behavior too: since your audio stimulus doesn't have the barrier, that means all responses are activated as soon as the stimuli are initiated (ignoring the delay, since that's just the presentation control). This is backed up by the fact that if you set the delay parameter to 0 for the choice response, it appears before the audio stimulus starts playing.

Crucially, that should also mean the background audio response has started recording. I assume you've set the relative duration as I described? If so, participants clicking on the choice response shouldn't abruptly cut the recording off.

Can you add [email protected] as a collaborator so that we can take a look? Maybe there's some cryptic bug here we can fix.

[sten_knutsen]

I've added you as collaborator. The block in question is "part_11" starting with the trial template "p11_trial_1_$A1-NAblack&pink and red.wav$A2-NULL$I1-NULL$I2-NULL$T1-socks$T2-NULL$M1-comp$M2-boundary$M3-grammatical"

As far as the duration property: my fix seems to work without it, and when I set the duration of the background audio response to anything other than 0, the fix breaks (the trials advance after pressing the choice button without letting the audio play through).

-- sten

[Ting]

Hi Sten,

Thanks for sharing the study with us! I think I understand the various combinations you've tried and why they worked or didn't work. I also have a recommendation at the end:

1. You current setup works, sort of, because the audio stimuli are universally relatively short. The reason why it works is because your background audio has no duration setting at all. This is important, because it means that the background audio response will record as long as the trial lasts. Now, importantly, because of the addition of the background audio response, the trial has more participant data to process and submit to the server, which takes just a little bit extra time that allowed the audio stimuli to finish playing. If your stimuli were a little longer, they would still be cut off.

In fact, on my fastest computer, if I manage to hit one of the buttons the moment I see them, the audio stimuli did get cut off. 

2. I've also tested giving an explicit duration to "p11_potato" the audio response. I find a duration of 4 seconds works really well. It makes sure that the trial will last at least 4 seconds to allow the audio stimuli to play through. If the participant clicks anything before the 4 seconds is over, the trial will simply wait there. I think this is what you wanted?

In that sense, #2 is exactly my understanding of how the findingfive study grammar works. It respects the duration of any background response when there are multiple responses (visible and/or background) on a trial. I would highly recommend doing that.

If you are not seeing the behavior I'm describing, can you clear the cache of your browser and reload everything. We did have a grammar update about 2 weeks ago.

Thanks!

[sten_knutsen]

Thank you -- this makes sense now!

-- sten