search

spatialaudio / python-sounddevice

:sound: Play and Record Sound with Python :snake:
https://python-sounddevice.readthedocs.io/
MIT License
1.01k stars 149 forks source link

No ASIO support in 0.5.0 #552

Open TonyBeswick opened 2 weeks ago

TonyBeswick commented 2 weeks ago

I see default ASIO support was removed in 0.5.0: https://github.com/spatialaudio/python-sounddevice/issues/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.

my1e5 commented 2 weeks ago

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 commented 2 weeks ago

Thanks for the feedback!

As I said in https://github.com/spatialaudio/python-sounddevice/issues/496#issuecomment-1787784922:

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 commented 1 week ago

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:

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 commented 1 week ago

I created a minimal PR of this in https://github.com/spatialaudio/python-sounddevice/pull/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 commented 1 week ago

@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 commented 1 week ago

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

mgeier commented 1 week ago

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.