[wdmaudiodev] Re: [EXTERNAL] Virtual Audio Passthrough Driver - data format conversion?

  • From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Mon, 19 Oct 2020 20:23:12 +0000

Expose some kind of custom driver interface (not KSCATEGORY_AUDIO.) Have your 
app WriteFile(…) or DeviceIoControl(…) the audio payload to this interface.

From: wdmaudiodev@xxxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxxx>
Sent: Monday, October 19, 2020 12:45 PM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: [EXTERNAL] Virtual Audio Passthrough Driver - data 
format conversion?


have your app give the networked voice data to your driver via a backchannel

I hadn't considered that, but it would avoid having the render endpoint appear 
in the sound settings, which would definitely be a GOOD THING.

Can you give me an example of what you mean by backchannel?

On 10/19/20 8:59 AM, Matthew van Eerde (Redacted sender Matthew.van.Eerde for 
DMARC) wrote:
Why do you need the virtual render endpoint? It would be simpler to have your 
app give the networked voice data to your driver via a backchannel, and then 
third-party apps can pick it up from your virtual capture endpoint.

From: wdmaudiodev@xxxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxxx>
Sent: Monday, October 19, 2020 8:55 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [EXTERNAL] [wdmaudiodev] Virtual Audio Passthrough Driver - data 
format conversion?

Hi everyone,

Tim Roberts over at the osr.com forum has been very kind in answering my audio 
driver questions over the last few months. Recently, he referred me to this 
mailing list where "all the cool audio driver kids, including several very 
helpful members of the Microsoft audio team, hang out".

My goal is to play networked voice data (in our app) to a virtual render 
endpoint, and have it 'loop-back' to a virtual capture endpoint that 3rd-party 
chat apps like Skype, Zoom, etc. can consume.

My audio driver prototype is based on SYSVAD/WaveRT. Besides being newer and 
recommended in the docs, WaveRT handles more of the copying data to/from the 
DMA buffers. My hope was that I could write less code and have a more stable 
driver.

What's needed is just a straight-through audio pipe, so I tried using a single, 
common buffer for render & capture streams; keeping the respective 
PlayPositions in sync. For this to have a hope of working, both render and 
capture streams would have to be identical in terms of format (e.g. channels, 
frames/sec). Alas, when I tested, each stream had significant differences in 
their PCM format (channels, frame rate). I'm still testing to see if I can 
limit/coerce both endpoints to the same format: a single channel at some 
arbitrary 'good enough' frame rate, but this approach is starting to look 
uncomfortably fragile.

My second prototype is based upon MSVAD/WaveCyclic. With WaveCyclic, I 
implement the DMA buffer copying logic, so I can do whatever data conversion is 
required. I'm aware of a few other 'virtual audio driver' projects on Github 
with similar goals; all based upon WaveCyclic.

I wanted to see how they dealt with the data format conversion issue, but when 
I look at their CopyTo and CopyFrom implementations, I don't see them dealing 
with conversion at all. There doesn't appear to be any code (e.g. in 
DataRangeIntersection) that limits streams to a specific number of channels or 
frame-rate.

Can anyone shed light on this?

I'm sure my expectations must be off somehow, but it seems to me that some kind 
of conversion must be required when copying data between streams of 
sufficiently different format...



Other related posts: