Audio playback crashes when Zoom is open

ekm

Hi! I was helping an RA with an OpenSesame study today, but if she ran the study while Zoom was open, it crashed with a portaudioerror error ("opening output stream invalid number of channels", probably because of ZoomAudioDevice?).

We were hoping to be able to use Zoom screenshare to actually conduct the study since we're doing research with children and an RA will have to be recording the participants' responses as they happen, but if this issue isn't fixable then we won't be able to do it. Do you have any suggestions/intuition about whether this is worth trying to sort out, or whether we should just go with a different stimulus presentation paradigm?

Thanks!

Fab

Hi @ekm,

So, you're running an Open Sesame experiment on your computer while sharing your screen with a participant through Zoom and you want to record the participant's responses. Can you specify what you mean by recording the participant's responses as they happen? You mean recording their video and audio feed on Zoom? Do participants have to produce responses within the Open Sesame task itself (with the RA clicking or responding for the participant?). I assume you don't want to measure the participants' responses within the task (key presses, response times etc.), otherwise what you should do is use OSWeb to generate a JATOS experiment from Open Sesame and then send your participant the link.

Do you encounter a portaudio error if sharing audio-visual applications other than Open Sesame? If not, then you might want to try different ways to run the experiment (within a window vs through your browser) to see if it makes a difference.

The problem might actually have to do with your sound card. Have you try running the whole thing frmo a different computer?

How do run Zoom? From your navigator or from the Zoom application installed on your computer?

I've just done a test on my computer and had no trouble recording a zoom meeting with audio and video and running Open Sesame on my computer. Here's what I did:

Computer 1 (experimenter): creating Zoom meeting from the Zoom application, with mic and camera on, sharing my screen, running an Open Sesame within a window, recording the zoom meeting using Zoom's recording tool

Computer 2 (participant): joined zoom meeting through my browser, with mic and camera on. Could see computer 1's shared screen, see the task run and hear its sounds stimuli too.

Recording worked fine. No audio conflict or error.

Try this configuration to see if it works for you too. If not, try the following:

• sharing another audio visual application to work out whether it has actually anything to do with Open Sesame, a different computer
• try from a different computer with different hardware to rule out a conflict related to your sound card or system

Hope this help. Good luck!

Fabrice.

ekm

Hi Fabrice,

Thanks for your reply and thorough suggestions for troubleshooting! I'll try to answer your questions here, but apparently the RA isn't consistently replicating the error anymore, so I may have been off-base about Zoom being the issue.

• Task questions: Since the participants will be children (supervised by their parents), they won't actually be producing responses within the Open Sesame task itself--the task is more like an interview guided by videos that the RA will present over OS. And yes, I think the plan is to record the Zoom call to capture that video and audio feed.
• Portaudio error if using things other than OS?: No, it seems to just be OS that gives that error. If the experiment isn't built for Open Sesame Web, is running it through the browser an option?
• Try running from a different computer?: We haven't tried yet, will give it a shot. :)
• How do you run Zoom?: From the Zoom application.

Thanks for testing it out yourself, too. I'll pass along your suggestions and let you know if we run into trouble again! All the best,

ekm

Fab

Hi @ekm ,

Thanks for the additional information. The developers of OS may be able to respond to the possible conflict between OS and Zoom re audio hardware, but my guess is that it's not a systematic conflict (I could run it simultaneously and record the session without any problem). It might however depend on what the task does, what audio-visual objects it uses etc. Hard to tell, really. If you haven't tried running the task through your browser locally (using the "run in browser button"), give it a go as it might use different memory resources and libraries than OS and possibly avoid the audioport conflict. Beware however that not all features of OS are compatible within a browser, however (see below).

Running your task from a JATOS server in a browser might possibly work out well. In that case, you could run your experiment entirely outside OS (so you wouldn't even have to open it). I've only begun using OS a few days ago but I have tried out some basic task as an online study and it works well. The logic is this: you program your task in OS, then you export it as a JATOS experiment through the Tools/OSWeb menu in OS. You then have to upload your JATOS experiment (it's single zip file containing the task and all files required by the task) to a JATOS server. If your institution runs JATOS on their server, you'll be able to use that. Otherwise, you can apply for a free user account with https://mindprobe.eu/ (it's a service supported by ESCOP and can be used to host and run online studies free of charge). To test your task out as you program it, a great option is the JATOS tryout server: https://www.jatos.org/JATOS-Tryout-Server.html. There are some limitations, however: not all objects from Open Sesame translate well to OSWeb, and code in Python won't work. You can however insert Javascript using the inline_javascript tool in OS. You can find out about the features that are and aren't supported here: https://osdoc.cogsci.nl/3.3/manual/osweb/osweb/#supported-functionality. You can read more info about OS here: https://osdoc.cogsci.nl/3.3/manual/osweb/osweb/ (there are also several videos on Youtube that you may find useful).

When exporting your experiment as a JATOS experiment, OS will tell you whether it detects compatibility issues. But be aware that that check is partial. You'll only know for sure when you try your task in your browser. A tip: if your task fails in the browser, use your browser's developers' tools to open the console. The information displayed there often helps identifying the origin of problems. One more tip: if your task uses a lot of text using the form_text_display, it won't work in a browser. Instead, replace these objects sketchpads on which you place text boxes.

One last thing: check whether you might have some other application or process open that takes control of the sound hardware. If the RA encounters that problem on and off, it may not be directly related to OS or Zoom but to the interaction between any or both of these with a third program. Try closing down all ongoing processes you don't need to see if it makes a difference.

Otherwise, running the task in a browser might work our better for you (especially running it online from a JATOS server, since in that case you just will need to have your browser and Zoom open, nothing else).

Hope this helps. Good luck!

Fabrice.