Open 10se1ucgo opened 7 years ago
Thanks for the suggestion! Is there a reason why this didn't make it back into the PortAudio upstream sources?
Oops, didn't see the email for this! As for why, I'm not entirely sure.
The only thing I could find was on the Audacity wiki: "Often the version of PortAudio used in Audacity has patches that have yet to make it back to the PortAudio SVN."
OK, so you (or somebody) should find out if this is planned to be included in the original PortAudio. Is there an open issue or pull request for that?
Once there is a pull request (or at least a published patch somewhere), this can be added to MXE, which is what I'm actually using to create the Windows binaries.
This would still be spectacularly useful, what do you think is the best way to progress this forward?
what do you think is the best way to progress this forward?
That's exactly what I tried to describe in my previous comment, which is a few years old, but AFAIK nothing has changed since (except probably that the MXE project has become a little less active).
I guess answering the question I've asked above would be a good first step.
In fact, I've asked two questions. The answer to either one would help.
This may need some searching on the PortAudio issue tracker and probably even needs some additional communication with the PortAudio team.
We (LedFx team) have made a PR for this - if you have any comments/want to review the PR, please have a look and comment if required.
Thanks for creating a PR for that!
With that, a loopback device should be created automatically, right?
So I guess we should not need any change in the sounddevice
module for the basic functionality.
However, we might think about supporting the additional API function PaWasapi_IsLoopback()
. Any suggestions for a Python API for that?
A quick and dirty way of finding the loopbacks is probably to find any device that has the same name as an WASAPI output device with "[Loopback]" appended to the end of it and input channels.
We're still squishing some bugs on that PR, and then there will obviously need to be a review and then wait for a release etc
edit: updated to reflect new loopback postfix formatting.
The PR is ready for testing - if anyone wants to build from my fork and test comments would be appreciated - https://github.com/PortAudio/portaudio/pull/672
@shauneccles I would like to correct regarding the use of (loopback)
string as identificator of the loopback device. The https://github.com/PortAudio/portaudio/pull/672 patch uses [Loopback]
identificator in the name of the loopback device.
So my advise is either:
[loopback]
string in the nameint PaWasapi_IsLoopback( PaDeviceIndex device )
and use it to detect loopback device with 100% guarantee.Postfixing WASAPI device name with [Loopback]
string will be frozen, so 1) can be a more or less reliable check.
Correct - the postfix has been updated since my comment - I'll update now :)
Thanks so much for your help @dmitrykos
Thanks everyone for pushing this forward!
I've created https://github.com/spatialaudio/python-sounddevice/pull/392, which makes the new PaWasapi_IsLoopback()
function available, but I haven't thought of a good Pythonic interface yet.
Any suggestions?
A few options I think - I wonder if as part of input device creation you PaWasapi_IsLoopback()
each input device, and return the value of that to a new entry in the sounddevice.check_input_settings
function, such as sounddevice.check_input_settings(loopback)
?
Alternatively, putting it inside sounddevice.check_input_settings(extra_settings)
return?
Audacity has patched version of portaudio in their source tree that implements support for WASAPI loopback mode, which allows you to capture from an output. It could be useful for some.