Importing sounddevice interrupts other audio streams on Windows when exclusive mode is enabled

[arkrow]

As the title mentions, importing sounddevice interrupts any currently playing audio streams momentarily on Windows when exclusive mode is enabled on the sound device. This issue seems to originate from PortAudio's initialization logic, however, I can't seem to pinpoint the problematic code there, and there isn't a similar issue opened there either.

To replicate the issue:

1. On Windows 10/11, enable exclusive mode on the default sound device.
2. Run any audio stream in the background (it doesn't seem necessary for the stream to be using exclusive mode)
3. import sounddevice (can be run in the python interactive interpreter; the current audio stream will be interrupted as a result)

This issue does not occur if exclusive mode is disabled in the sound device. I'd assume this issue can be reproduced on Windows 7 as well.

[mgeier]

This issue seems to originate from PortAudio's initialization logic, however, I can't seem to pinpoint the problematic code there, and there isn't a similar issue opened there either.

Then you should open one!

This doesn't seem like anything that can be solved from the Python side.

To be sure, you could replace your step 3 with some other software that uses PortAudio, for example Audacity, and listen if it behaves the same.

[arkrow]

To be sure, you could replace your step 3 with some other software that uses PortAudio, for example Audacity, and listen if it behaves the same.

Great call. I've tested the same scenario with Audacity and it doesn't exhibit this issue. In fact, using Audacity's PortAudio binary (instead of the ones linked in _sounddevice_data) solves the issue. From what I can gather, Audacity's PortAudio binary is based on the 19.7 release, same as here, confirmed by comparing .Pa_GetVersion() for both libraries (though the revision is unknown for Audacity's binary). Regardless, the discrepancy in behavior is unexpected.

[mgeier]

Hmm, that's interesting.

I don't know exactly how the DLL from Audacity is built, probably with Conan. I found https://github.com/audacity/audacity/blob/52708c770ffcd98cb86527cd7756413c4179f7fe/conan/conanfile.py#L119-L121, which suggests that WDM-KS is disabled. Maybe that causes the problem? It could be something completely different, though.

I don't know if that helps, but you could also try some older versions of the DLL, e.g. https://github.com/spatialaudio/portaudio-binaries/blob/d9765fc440e4181576b5a801afd2e3624ac2edd9/libportaudio64bit.dll and https://github.com/spatialaudio/portaudio-binaries/blob/bab7ef6a62415c2c83bdb632585fa439d3edc48b/libportaudio64bit.dll.

[mgeier]

I made a little experiment building the DLL with MSVC, can you please try the DLL from https://github.com/spatialaudio/portaudio-binaries/actions/runs/6523747765?

[arkrow]

All three linked binaries unfortunately exhibit the same issue.

I don't know exactly how the DLL from Audacity is built, probably with Conan. I found https://github.com/audacity/audacity/blob/52708c770ffcd98cb86527cd7756413c4179f7fe/conan/conanfile.py#L119-L121, which suggests that WDM-KS is disabled. Maybe that causes the problem? It could be something completely different, though.

Audacity's PortAudio binary does indeed support fewer APIs, namely just: MME, DirectSound and WASAPI; while the PortAudio bundled with sounddevice is built with ASIO and WDM-KS support enabled.

To help triangulate the root cause, I've tested another PortAudio binary and found that FlexASIO's bundled PortAudio binary also does not exhibit the issue like Audacity's. The most distinct differences are that it's built without the ASIO SDK (so API support is the same as sounddevice, minus ASIO), and it's built using a more recent commit from PortAudio's master branch: 80ef9ac.

[mgeier]

Thanks for testing this. It's good to know that switching from MXE cross-compiling (on my local computer) to directly compiling with MSVC (via Github Actions) doesn't change the behavior.

Feel free to experiment with my github-action branch, where you can select any PortAudio commit (see https://github.com/spatialaudio/portaudio-binaries/blob/7e139d8202945feff9150b550684d28ab7f6f43a/.github/workflows/build-libs.yml#L13) and any combination of host APIs (see https://github.com/spatialaudio/portaudio-binaries/blob/7e139d8202945feff9150b550684d28ab7f6f43a/.github/workflows/build-libs.yml#L28).

[arkrow]

After some experimentation compiling different builds of PortAudio, it's clear that building PortAudio with ASIO causes the problem.

Since the problem is upstream and its root cause unclear (could be PortAudio or the ASIO SDK), would it be possible to modify sounddevice to conditionally load a non-ASIO PortAudio binary instead, using an os.environ flag at import time? I think that would be the simplest workaround, especially for those that do not require ASIO for their use case. I can provide the PR for this change, if a non-ASIO binary is added to spatialaudio/portaudio-binaries.

[mgeier]

Thanks for testing this, that's very interesting.

would it be possible to modify sounddevice to conditionally load a non-ASIO PortAudio binary instead,

Well, this should already be possible, but it is platform-dependent.

On Linux, you can simply put a custom libportaudio.so into the directory /usr/local/lib/, and the sounddevice module should use that one automatically.
In some cases you might have to call sudo ldconfig for the new library to be found.

On macOS it should work similarly.

On Windows, however, I don't know if/how it works.
I guess the custom DLL has to be placed somewhere where ctypes.util.find_library() can find it.

We might also have to add another library name to the code:

python-sounddevice/sounddevice.py

Lines 63 to 65 in 4aa98dc

	'portaudio', # Default name on POSIX systems
	'bin\\libportaudio-2.dll', # DLL from conda-forge
	'lib/libportaudio.dylib', # dylib from anaconda

It would be great if you could check this out and suggest any changes that are necessary to make it work properly.

using an os.environ flag at import time?

Yes, this might also be possible, it has already been discussed some time ago: #130.

[...] if a non-ASIO binary is added to spatialaudio/portaudio-binaries.

Providing a different DLL is a follow-up concern, but if we create the DLLs with CI (as in my experimental github-action branch), it should be straightforward to provide multiple variants of the DLL.

[Prosperelucel]

Hello,

I wanted to confirm that when using the .dll from the FLEXASIO .exe, other audio streams are not interrupted when I import the sounddevice module in Python 3.10 on Windows 10. I simply replaced the Lib\site-packages_sounddevice_data\portaudio-binaries\libportaudio64bit.dll with the portaudio.dll from the FlexASIO\x64 folder, and then renamed it.

Thank you for providing this workaround!

[arkrow]

I guess the custom DLL has to be placed somewhere where ctypes.util.find_library() can find it.

I think the best approach would be bundling it with sounddevice rather than installing the alternative binary separately. I've had several users report the same problem, so it would be great if this is a possible option to consider. I've opened PR #498 to demonstrate my suggested change for this issue while being fully backwards-compatible, but I'm very much open to feedback and changes in approach.

Thank you for providing this workaround!

Glad to help, thanks for confirming @Prosperelucel

[mgeier]

Before jumping into work-arounds, I would like clarification on two questions:

• does this problem still occur on the master branch of PortAudio?
• is the PortAudio project aware of this problem?

It would be good to know if this has been discussed already in the PortAudio project and if there are any ideas to solve this within PortAudio.

There should at least be an issue at https://github.com/PortAudio/portaudio/issues before we start a work-around here.

[arkrow]

does this problem still occur on the master branch of PortAudio?

Yes, unfortunately.

is the PortAudio project aware of this problem?

Latest ongoing discussion: PortAudio/portaudio#858

Relevant issues in the PortAudio project:

• PortAudio ASIO driver scan PortAudio/portaudio#696
• Windows: just calling Pa_Initialize kills audio in other apps PortAudio/portaudio#564

It would be good to know if this has been discussed already in the PortAudio project and if there are any ideas to solve this within PortAudio.

There should at least be an issue at https://github.com/PortAudio/portaudio/issues before we start a work-around here.

Alright, sounds great. Ideally, the issue is resolved upstream and a new version of sounddevice can then be released with the fixed PortAudio binaries. However, it seems that the issue is much more fundamental with PortAudio's ASIO support. That said, I'm open to seeing where the ongoing issue discussion at PortAudio leads and alternative ideas with regards to this issue's fix.

[mgeier]

Thanks for further looking into that!

I found this interesting:

PortAudio/portaudio#696 (comment):

I suspect many people building PortAudio are not aware that PortAudio's ASIO support is a giant footgun in that regard.

I'm one of those people who were not aware of that.

Do you also experience the startup delay mentioned at PortAudio/portaudio#696 (comment)?

I'm wondering if we should provide a DLL without ASIO by default and provide a work-around to enable ASIO for those who need it?

I don't know how many people actually want to use the sounddevice module with ASIO, but according to the discussions in the issues you mentioned, there are people who want to use ASIO (but maybe not in a Python context?).