Repository navigation
Unable to use subprocess.check_output with sounddevice 0.4.6 #461
Description
Unable to call subprocess.check_output after importing sounddevice 0.4.6
Output error: [WinError 50] The request is not supported
System: Windows 10 and 11
Python: 3.11.2
sounddevice 0.4.6
pyinstaller 5.9.0
Easy reproduction
- Write script aaa.py
import subprocess
output = subprocess.check_output("ECHO before import", shell=True)
print(output)
import sounddevice
output = subprocess.check_output("ECHO after import", shell=True)
print(output)
- Build using pyinstaller 5.9.0
python -m PyInstaller --onefile aaa.py
aaa.exe
> b'before import\r\n'
> Traceback (most recent call last):
> File "aaa.py", line 7, in <module>
> File "subprocess.py", line 466, in check_output
> File "subprocess.py", line 548, in run
> File "subprocess.py", line 892, in __init__
> File "subprocess.py", line 1378, in _get_handles
> File "subprocess.py", line 1387, in _make_inheritable
> OSError: [WinError 50] The request is not supported
Activity
mgeier commentedon Mar 19, 2023
Thanks for the report!
Can you please try it with an older
sounddeviceversion, e.g. 0.4.5?Maybe #444 caused the problem ...
And could you try to somehow get a traceback to see where the
OSErroris happening?micgrzyw commentedon Mar 20, 2023
Hi :)
Yes, 0.4.5 works fine. #444 indeed looks like a root cause
Is this traceback sufficient?
mgeier commentedon Mar 26, 2023
It's not sufficient for me to understand the problem, since it doesn't point to the offending code in
sounddevice.py.I guess one way to find out which line causes the problem would be to deactivate the changes from #444 line-by-line until the exception doesn't happen anymore.
ozgaprzx commentedon Jul 31, 2023
I observed a similar case - such an error is shown in version 0.4.6, but after reverting the import to 0.4.5 we do not observe the error anymore.
micgrzyw commentedon Aug 7, 2023
Hi @mgeier!
This issue is observed by more than me in our project. Yes, everything works with sounddevice 0.4.5, however we would like to unblock using 0.4.6 and future updates.
Change #444 blocks using a subprocess module in built application on Windows platforms as described above. If I revert this change manually, then the problem does not reproduce, so it is clearly a rootcause. However I wouldn't want to make a dirty changes in 3rd party component in our project.
Is it possible to revert this change and make a new release? Please let me know if there are any plans to fix this issue.
And many thanks for your support!
ndahn commentedon Mar 31, 2026
Still seems to be an issue sadly :/
mgeier commentedon Apr 1, 2026
Feel free to do more research and experimentation and provide an explanation/solution/work-around.
For starters, you could create a MRE (i.e. without using
sounddevice) and ask an LLM why it doesn't work.ndahn commentedon Apr 1, 2026
I'll look into it over the next few weeks, sounddevice is a central part of my app ~
ndahn commentedon Apr 22, 2026
After a short claude session this is the underlying issue:
The root cause is that sounddevice's _initialize() manipulates file descriptor 2 (stderr) using os.dup/os.dup2 to temporarily redirect it to /dev/null during PortAudio initialization.
On Windows in a PyInstaller binary, stderr is not a real console handle. This causes the dup/dup2 operations to corrupt the Windows CRT's internal file descriptor / handle inheritance table. Once corrupted, any subsequent subprocess call that touches stdout/stderr handle inheritance fails with WinError 50: the request is not supported.
I have created a PR which fixes this (and have confirmed it works :) ).
Do you think you will make a new release anytime soon, or should I keep a monkey patch in my app?
mgeier commentedon Apr 25, 2026
Thanks for looking into that, @ndahn!
This sounds quite reasonable, but it would be much more convincing if you could create an MRE that doesn't use
sounddevice(butos.dup()etc. directly).With this, it would also be interesting to ask the PyInstaller people for advice, maybe they have some additional ideas ...
I'm willing to accept #628 eventually, but ideally I would like to see this problem confirmed outside the context of the
sounddevicemodule.Once a solution for this is merged, I can quickly make a new release, that's not a lot of effort.
ndahn commentedon Apr 26, 2026
Alright, thank you! I'll create an MRE the next few days and see if I can find something on pyinstaller as well (so far I didn't).
ndahn commentedon May 9, 2026
Alright, sorry for the delay. I finally found some time to look into this further. The most basic example where
stderris set todevnullactually works fine. The problems only come up whenstderris modified and_lib.Pa_Initialize()is called. My suggested workaround still works, but the problem is somewhere in the dll it seems.To try it, compile the python script with
pyinstaller test.py --onefile, then copy thelibportaudio64bit.dllfrom_sounddevice_datato into thedistdirectory. You can also try the asio dll, same result.mgeier commentedon May 23, 2026
Thanks for looking into this!
So we still don't know what
Pa_Initialize()does to cause this behavior, it is still quite mysterious.Could you please ask at https://github.com/pyinstaller/pyinstaller/issues whether they have any idea what happens there and if there is a way to avoid this (apart from disabling the call, which you showed to work already)?