Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Audacity's WASAPI patched portaudio source #6

Open
10se1ucgo opened this issue Sep 1, 2017 · 13 comments
Open

Use Audacity's WASAPI patched portaudio source #6

10se1ucgo opened this issue Sep 1, 2017 · 13 comments

Comments

@10se1ucgo
Copy link

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.

@mgeier
Copy link
Member

mgeier commented Sep 4, 2017

Thanks for the suggestion!
Is there a reason why this didn't make it back into the PortAudio upstream sources?

@10se1ucgo
Copy link
Author

10se1ucgo commented Sep 29, 2017

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."

@mgeier
Copy link
Member

mgeier commented Oct 12, 2017

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.

@shauneccles
Copy link

This would still be spectacularly useful, what do you think is the best way to progress this forward?

@mgeier
Copy link
Member

mgeier commented Nov 15, 2021

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.

@shauneccles
Copy link

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.

@mgeier
Copy link
Member

mgeier commented Nov 27, 2021

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?

@shauneccles
Copy link

shauneccles commented Nov 28, 2021

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.

@shauneccles
Copy link

The PR is ready for testing - if anyone wants to build from my fork and test comments would be appreciated - PortAudio/portaudio#672

@dmitrykos
Copy link

@shauneccles I would like to correct regarding the use of (loopback) string as identificator of the loopback device. The PortAudio/portaudio#672 patch uses [Loopback] identificator in the name of the loopback device.

So my advise is either:

  1. Convert device name to low case and search for [loopback] string in the name
  2. Somehow export native API int 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.

@shauneccles
Copy link

Correct - the postfix has been updated since my comment - I'll update now :)

Thanks so much for your help @dmitrykos

@mgeier
Copy link
Member

mgeier commented Feb 8, 2022

Thanks everyone for pushing this forward!

I've created spatialaudio/python-sounddevice#392, which makes the new PaWasapi_IsLoopback() function available, but I haven't thought of a good Pythonic interface yet.

Any suggestions?

@shauneccles
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants