markheath
commented
7 months ago Afraid I have no idea whether this will work for you. WasapiLoopbackCapture is relatively easy to use, but there will be an amount of latency that you might need to take into account which might make it hard to visualise sound in real-time. You'll get the samples as stereo IEEE floating point samples, at either 48 or 44.1kHz
I have a library which uses OpenAL to process loopback data and write the resulting information to OpenGL texture buffers for further processing by audio-reactive music visualization shaders. However, on Windows it requires installing a loopback driver. I'm interested in using NAudio's WasapiLoopbackCapture feature as an alternative to the third-party driver requirement (which has drawbacks beyond simple inconvenience).
Are there any caveats or known problems running capture on a background thread?
The overhead of music visualization shaders can be high (some run at thousands of frames per second), and neither OpenAL or OpenGL are "officially" threading-friendly libraries. A lot of very careful locking and synchronization-signalling is required to continuously generate new realtime "audio texture" data, which would be impossible if audio capture was regularly interrupting the foreground visuals thread.
Before I tackle the integration of a completely new library, I figured I'd ask if this is considered "a really bad idea" with NAudio, or perhaps even specifically known to be impossible.
The details probably don't matter here, but I capture raw mono-downmixed PCM data in batches of 1024 samples. They are then variously post-processed into different buffers as FFT decibel and magnitude, RMS volume, WebAudio API "smoothed" decibel data, etc. ... but PCM is all I need from the capture perspective.