[wdmaudiodev] Re: Writing an "unavoidable", "filter-like" audio driver

  • From: "learncyber" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "learncyber" for DMARC)
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 06 Oct 2020 07:18:23 +0000

Thanks for answering!
To my understanding, voicemeeter is an application, and so other applications 
will be able to bypass it and access data directly from audio sources. If that 
so, I'm afraid it will not meet my need for a way to manipulate audio data 
which is "unavoidable" by applications.

If I'm wring, please let me know and I will be happy to try it out!

Many thanks again.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, 5 בOctober 2020 08:52, Vincent Burel \(VB-Audio\) 
<vincent.burel@xxxxxxxxxxxx> wrote:

Hello,

"to manipulate audio" coming from any input (MIC , Line-in... ) or 
applications, you can today use the Voicemeeter AUDIO API as simpler 
alternative. It allows you to build a simple client application that will 
just register a simple audio callback to get all audio stream managed inside 
Voicemeeter.

See Voicemeeter remote API section in this page:
https://vb-audio.com/Services/support.htm

Regards
Vincent Burel
www.vb-audio.com

-----Message d'origine-----
De : wdmaudiodev-bounce@xxxxxxxxxxxxx 
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Tim Roberts
Envoyé : dimanche 4 octobre 2020 21:08
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: Writing an "unavoidable", "filter-like" audio driver

On Oct 4, 2020, at 4:29 AM, learncyber (Redacted sender "learncyber" for 
DMARC) dmarc-noreply@xxxxxxxxxxxxx wrote:

I'm interested in writing a driver that will manipulate data coming from a 
microphone, in a way that will affect every user-mode application accessing 
it (for example, adding audio effects). Concretely, any user-mode app that 
will try to access the microphone (i.e recording app, webcam app etc.) will 
not be able to retrieve the original data, but only the data after 
modification by the driver.
The driver should be implemented in a way that will "unavoidable" by the 
applications, meanning applications will not be able to bypass it and gain 
direct access to data coming from a microphone.

Can’t be done. One of the primary reasons behind the redesign of the Windows 
audio system in Vista was that too many people had written “unavoidable” 
filter drivers in order to “enhance” the user experience, and the net result 
was that it became totally impossible for professional audio applications to 
get the latency guarantees they needed in order to do real work. One 
fundamental principle of the new design is that there will ALWAYS be an 
“exclusive” mode that provides direct access to the audio hardware.

Now, to my (limited) unserstanding, the current windows audio pipeline 
design is: microphone -> IHV driver -> Audio Engine -> application.
My question is, is it possible to interfere in the pipeline before the 
Audio Engine? for example, attach a "filter-like" driver between the IHV 
driver and the Audio Engine, or maybe between the microphone and the IHV 
driver?

No. The IHV driver is not involved in the data transfer. Today’s WaveRT audio 
hardware has a circular buffer for data on the device. The driver maps that 
circular buffer directly into the Audio Engine process at initialization 
time, and then participates no more. The Audio Engine copies the data to and 
from the hardware directly without involving a driver.

The audio subsystem does have the concept of “effects APOs” (audio processing 
objects), which are filters that can sit in various places in the audio 
processing graphs. However, those are not generic system-wide filters; the 
APOs are considered part of the driver, and so have to be installed as part 
of a driver package. And, as I mentioned above, an application can always 
request “exclusive mode” to stream data without involving the APOs.

Put simply, what you’re asking is directly contrary to Microsoft’s philosophy 
for the audio subsystem. Attempting to implement something contrary to 
Microsoft’s philosophy is always going to lead to tears.

Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/


******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/

Other related posts: