Feature Request: WASAPI loopback recording

[darronmcnutt]

Audacity uses a patched version of PortAudio that enables loopback recordings using WASAPI. Adding this functionality to sounddevice would be very helpful for me in my work testing audio conferencing hardware. In my tests, I have a need to compare THD+N of a reference stream with THD+N of a stream traveling through the device under test. Please let me know if it is possible to add this feature. If not, suggestions for workarounds or alternatives would be most welcome. Thank you!

Audacity manual: https://manual.audacityteam.org/man/tutorial_recording_computer_playback_on_windows.html

Discussion: https://github.com/tlecomte/friture/issues/64

[mgeier]

See https://github.com/spatialaudio/portaudio-binaries/issues/6.

You can also compile your own PortAudio DLL and use it with the sounddevice module.

suggestions for workarounds or alternatives would be most welcome.

Why do you need a loopback device for that? You already have the relevant signal, right? Sending it through the loopback device shouldn't change the signal. Except of course for the delay, but you'll have to compensate for that anyway (because the loopback device won't have the same latency as your DUT, right?).

[darronmcnutt]

Thanks for your reply. We are generating a sine wave according to the example here: https://python-sounddevice.readthedocs.io/en/0.4.1/examples.html#play-a-sine-signal

Through our testing we have found that the sine wave data occasionally does not make it into the output stream in time to meet real-time audio deadlines. In our tests, the status parameter here: callback(indata, outdata, frames, time, status) gives no indication that audio samples are being dropped. These failures occur silently with no indication of error.

The first part of our signal flow is as follows: sounddevice --> Dante Virtual Soundcard --> Dante-capable device under test --> Analyze output THD+N

To analyze THD+N we capture audio from the DUT's Dante outputs or Windows audio driver outputs. Since it is crucial for us to know whether audio artifacts are introduced by the DUT or at the beginning of the audio chain with Python/sounddevice/Port Audio, when need to capture a loopback recording and compare with our output recording from the DUT.

Our software verification department consists entirely of Python developers, so it would be of great benefit to us to have access to loopback recording at the Python level without the need to roll our own customized Port Audio dll. Thanks again for your help!

[mgeier]

In our tests, the status parameter [...] gives no indication that audio samples are being dropped. These failures occur silently with no indication of error.

This is bad, I guess this is a bug in PortAudio. Probably related to https://github.com/PortAudio/portaudio/issues/303?

What about using WASAPI's "exclusive" mode?

Are there any other host APIs that are supported? WDM-KS? ASIO?

it would be of great benefit to us to have access to loopback recording at the Python level

Sure, I'm open to that. I've described the process in https://github.com/spatialaudio/portaudio-binaries/issues/6.

[sveinse]

I make an end-user program for testing home cinema setups, https://elns.netlify.app/, which is based on Portaudio. I needed loopback support too, so I have patched PA and imported the Audcity portaudio patch into my own branch. The patch for adding loopback in to wasapi isn't that big:

https://github.com/sveinse/portaudio/commit/c511c79e8ff17b30b2ed81baaa09a35bb75e8154

Of course we all agree that it would be best if this were to find its way into portaudio.

[darronmcnutt]

Thanks! We initially observed this same issue (dropouts with no indication of error) with ASIO and DirectSound. The issue is not unique to WASAPI and is reproducible across multiple systems at our company.

[sveinse]

@darronmcnutt that's interesting that you observe dropouts in ASIO and DirectSound too. I have stable operation in all host APIs, including DS and ASIO (to Focusrite Scarlett. I haven't tried my app with DVS yet, but definitely I need to). My py app is using pyaudio and not sounddevice thou. In any case, perhaps an issue need to raised in https://github.com/PortAudio/portaudio for this?

(Sidenote: I think I need to take a look at sounddevice and what it offers compared to pyaudio.)

[s0d3s]

Hello, in one of the latest PortAudio commits(issue), enough functionality has been added to work with WASAPI loopback devices.

Adapting this to sounddevice should not be a problem. The hardest part is recompiling your shared libraries ;)

I put together a similar one for PyAudio(PyAudioWPatch).