If I follow Tim’s recommendation, the idea is to use an ordinary audio DDI to
get audio INTO your virtual speaker (which could certainly be waveRT), but to
use a private IOCTL of your own design to get audio data OUT (so you would not
use waveRT or any other audio DDI for this part.)
From: Giacomo Costantini<mailto:giacomo.costantini3@xxxxxxxxx>
Sent: Thursday, May 7, 2020 1:22 PM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [EXTERNAL] [wdmaudiodev] Re: VAD processing and re-routing streams
Hi Tim,
Thanks again for your input.
I have seen that normally IOCTL is used with WaveCyclic and WavePCI, but I also
know that theoretically WaveRT is the best choice to guarantee realtime
performances.
The only tricky thing about it in an audio driver is that the port class driver
has already taken over your request dispatching. You’ll have to go install a
handler for IRP_MJ_DEVICE_IO_CONTROL after calling PcInitializeAdapterDriver.
Does it work with WaveRT as well?
I’ve spent some time trying to figure out how to get the dma buffer from
WaveRT streams in the SYSVAD example, but to be honest I do still do not
understand what actual mechanism should be in place to dialogue with WaveRT.
That makes me wonder if WaveRT is the best choice for my needs (routing audio
from my VAD’s output to a real output, using an application) and wether I
should use something else or even a loopback mechanism.
In the SYSVAD sample, the content of the buffer is saved in an audio file by
default (through CMiniportWaveRTStream::ReadBytes ), that makes me think it
should be relatively easy to get that stream from an application, but I still
do not see how to do that in practice and I have no specific code nor
documentation references.
Anyone that can help me out with that?
Best,
Giacomo Costantini
On 29 Apr 2020, at 03:52, Tim Roberts <timr@xxxxxxxxx<mailto:timr@xxxxxxxxx>>
wrote:
On Apr 28, 2020, at 3:29 AM, Giacomo Costantini
<giacomo.costantini3@xxxxxxxxx<mailto:giacomo.costantini3@xxxxxxxxx>> wrote:
Their driver exposes private ioctls that are used by the application to access
a circular buffer of data. I've done two solutions that use this same
technique.
That starts to make some sense, thanks for the info.
I am not very familiar with IOCTLs on Windows, so if there is any code or more
specific documentation you can share or point me to, that would be of great
help.
Virtually every driver sample handles ioctls, although you’ll need to find one
that doesn’t use KMDF.
The only tricky thing about it in an audio driver is that the port class driver
has already taken over your request dispatching. You’ll have to go install a
handler for IRP_MJ_DEVICE_IO_CONTROL after calling PcInitializeAdapterDriver.
—
Tim Roberts, timr@xxxxxxxxx<mailto:timr@xxxxxxxxx>
Providenza & Boekelheide, Inc.
