| Reference | Downloads | Github

Psychopy not quitting on core.quit() or sys.exit(0)

I can’t seem to get the experiment window to close after the experiment has concluded using either core.quit() or sys.exit(). After the final screen has shown, the window simply hangs and in order to quit one needs to manually press the “stop” button in the IDE instead of having the application quit gracefully. I know the rest of the program isn’t hanging because it successfully prints verification output before it’s supposed to quit. Is there any better way to force the experiment window to close?


What IDE are you using? Coder, Spyder, or something else? I had problems like this in Spyder when scripts were set to run in the ipython console. Ticking “run in new python process” (or something like that) solved the problem.

If you put a print statement after core.quit(), does it print? You could also try and run win.close(), although core.quit() should do that.

Are you on a Mac, using one of the recent 64bit releases and using pyo (default sounds)? This is a known problem.

Indeed I am. The experiment fails to quit on 1.84 on older 32bit Macs running older versions of OSX, as well. Perhaps I should manually specify the other sound library?

yes that is exactly what you need to do

Hej tahabi and jon, I seem to have the same problem (psychopy not quitting and running a recent 64bit release and using pyo). To my knowledge, I had manually specified pyo with the commands:
from psychopy import prefs
prefs.general[‘audioLib’] = [‘pyo’]

But the problem is still there. tahabi, what do you mean with “the other sound library”? What am I missing here?


Sorry, guys… the problem appears to have been the following:

This order of imports didn’t work:
from psychopy import prefs
prefs.general[‘audioLib’] = [‘pyo’]
from psychopy import core, visual, data, misc, event, logging, gui, sound,

This order of imports does work:
from psychopy import core, visual, data, misc, event, logging, gui, sound, prefs
prefs.general[‘audioLib’] = [‘pyo’]

This is probably completely obvious to you… to me it wasn’t.
Thanks :wink:

Actually @thomaswolf.cogsci I think the method you used in the first place is the one you want if your intention is to use pyo! I think what this suggests is that pyo is not working properly on your machine and causing it not to load.

If you go to the audio preference in psychopy (or print it from your script rather than setting) I think it will tell you that something else is being set by default (which is working) and that setting the preference to [‘pyo’] is causing the crash. The second code you’ve shown is (I think) setting the sound lib after it has already been initialised and has no effect.

All this will hopefully go away if we manage to find an alternative to pyo (I’ve added a new option recently that I’m hoping will be a good alternative)

hmm… I manually switched the order in the settings from [‘pygame’, ‘pyo’] to [‘pyo’, ‘pygame’] and exiting works again.
most of the time… I will post again when I have more conclusive experience with what’s going on.

My newest hypothesis is that the freezing occurs, because of an issue with pyo server. In my case (I want to use the sound module and the voicekey module) the experiment crashes when voicekey tries to initialize a pyo server even though the sound module has already initialized one.
I have learned that you cannot have two pyo servers at the same time. The solution seems to be to share the one server created by the sound module with the voicekey module. I found a reference to this in a discussion on github:

My only remaining question: how do I link sound and voicekey to the same server?


The sound module should be imported sooner.

we changed the generated import statements:

from psychopy import locale_setup, visual, core, data, event, logging, sound, gui

from psychopy import sound
from psychopy import locale_setup, visual, core, data, event, logging, gui

and core.quit() no longer freezes.

@jon: can you change the Psychopy Builder script compiler so that it imports the sound module earlier? It might be a good idea to also import the visual module earlier.