Hi,
Is there any sample code/documentation on how to write virtual audio driver using the WaveRT interface?
MSVAD sample drivers provided with WinDDK implements WvaeCyclic interface.
I would really appreciate any pointers to sample code for virtual audio driver using WaveRT interface.
Thanks!
xxxxx@gmail.com wrote:
Is there any sample code/documentation on how to write virtual audio driver using the WaveRT interface?
What’s the point? WaveRT was designed for real hardware. It assumes a
real bus connection with bus-mastered DMA. In WaveRT, the actual data
transfer is not done by the kernel driver – it’s done by the user-mode
audio engine.
MSVAD sample drivers provided with WinDDK implements WvaeCyclic interface.
Right, and that’s how virtual drivers should be implemented.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
Thanks for your reply.
I am new to driver development. I am trying to convert a wavecyclic implementation of a virtual audio driver to a waveRT one. My virtual driver aims at capturing all audio streams and write it to my client application’s buffer which sends it over the network.
Do you mean there would be no performance advantage(less latency) of converting a wavecyclic virtual driver to the waveRT one?
I was under the impression that since the driver directly maps the application’s buffer (like windows media player) to the audio driver’s cyclic buffer in waveRT, it would cause less latency. Is this optimization possible only with real audio drivers and not the virtual ones? Can you please explain what would happen in a virtual driver case then? I am a little lost here since I could not find any documentation which explains about implementing a virtual driver using waveRT interface 
Thanks again!
xxxxx@gmail.com wrote:
Do you mean there would be no performance advantage(less latency) of converting a wavecyclic virtual driver to the waveRT one?
Not unless you have real hardware.
I was under the impression that since the driver directly maps the application’s buffer (like windows media player) to the audio driver’s cyclic buffer in waveRT, it would cause less latency. Is this optimization possible only with real audio drivers and not the virtual ones?
No, the application does not write directly into the circular buffer.
The application makes the same API calls it has always made, but those
calls are directed to the magical Audio Engine, which is a special
user-mode service. It is the Audio Engine that has the hardware’s
circular buffer directly mapped. It still has to copy the data between
the user’s buffer and the circular buffer.
In WaveRT, the audio hardware is directly monitoring that circular
buffer. When the Audio Engine application copies the data in and
updates the circular buffer pointers, the hardware immediately takes
action to process that data. It does not wait for a driver command. In
fact, a WaveRT driver is not involved in streaming in any way. It never
gets called. That is the key benefit of WaveRT, and the key problem
with making a virtual WaveRT driver.
Can you please explain what would happen in a virtual driver case then?
Nothing would happen. That’s why it won’t work.
I am a little lost here since I could not find any documentation which explains about implementing a virtual driver using waveRT interface
Right, because there is no way for it to do so.
You should not care about making a virtual WaveRT driver. What you care
about is making a virtual audio driver. You do that using the
WaveCyclic model, just like you have now.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> fact, a WaveRT driver is not involved in streaming in any way. It never
gets called.
What about the “update pointers” call?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim S. Shatskih wrote:
> fact, a WaveRT driver is not involved in streaming in any way. It never
> gets called.
What about the “update pointers” call?
There is no such call. During negotiation, there is a property request
that returns the mapped virtual address of the hardware’s pointer
registers. The Audio Engine service writes those pointer registers
directly. There are no user/kernel transitions when reading or writing
audio data.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On 31-Jul-2012 19:12, Tim Roberts wrote:
Maxim S. Shatskih wrote:
>> fact, a WaveRT driver is not involved in streaming in any way. It never
>> gets called.
> What about the “update pointers” call?There is no such call. During negotiation, there is a property request
that returns the mapped virtual address of the hardware’s pointer
registers. The Audio Engine service writes those pointer registers
directly. There are no user/kernel transitions when reading or writing
audio data.
Given this, how can we insist that direct mapping of i/o memory to
usermode is bad?
– pa
Pavel A wrote:
On 31-Jul-2012 19:12, Tim Roberts wrote:
> There is no such call. During negotiation, there is a property request
> that returns the mapped virtual address of the hardware’s pointer
> registers. The Audio Engine service writes those pointer registers
> directly. There are no user/kernel transitions when reading or writing
> audio data.
Given this, how can we insist that direct mapping of i/o memory to
usermode is bad?
The white paper on WaveRT miniport drivers has a paragraph that
addresses this, and talks about hardware design strategies to minimize
the risk. For the most part, it dances around the topic.
We all know that the danger depends on the cost of an intrusion. In
this case, the only cost of a break-in by a malicious process would be
to mess up your playback of Taylor Swift’s latest song.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim for your reply.
So, for waveRT, is there no DMA transfer which takes place between the circular buffer to the hardware buffer? Is hardware buffer mapped to the circular buffer and audio engine is directly writing to the hardware buffer?
xxxxx@gmail.com wrote:
So, for waveRT, is there no DMA transfer which takes place between the circular buffer to the hardware buffer?Is hardware buffer mapped to the circular buffer and audio engine is directly writing to the hardware buffer?
That’s the intended design, yes. Direct mapping.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Pavel A wrote:
>> On 31-Jul-2012 19:12, Tim Roberts wrote:
>>> There is no such call. During negotiation, there is a property request
>>> that returns the mapped virtual address of the hardware’s pointer
>>> registers. The Audio Engine service writes those pointer registers
>>> directly. There are no user/kernel transitions when reading or writing
>>> audio data.
>> Given this, how can we insist that direct mapping of i/o memory to
>> usermode is bad?
>
> The white paper on WaveRT miniport drivers has a paragraph that
> addresses this, and talks about hardware design strategies to minimize
> the risk. For the most part, it dances around the topic.
>
> We all know that the danger depends on the cost of an intrusion. In
> this case, the only cost of a break-in by a malicious process would be
> to mess up your playback of Taylor Swift’s latest song.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
The security aspect of direct i/o space access IMHO is the last
to worry about. - because no existing Windows product holds
any hope against malware, as recent findings have shown.
But will bad things happen when power management
processing isn’t synchronized with access from usermode:
for example, consider when a PCI device does to D3
or PCIe link down state, while usermode app keeps
banging thru a BAR mapping on it?
And providing sync between the app and driver will
add complexity, overhead, and even then won’t be 100% reliable.
What do you think?
Regards,
– pa
Not to mention what happens after an IRP_MJ_PNP:IRP_MN_STOP_DEVICE
notification, when the BARs are mapped out of existence.
The need to access hardware from user space seems to be the first resort
of people who really don’t understand operating systems, device drivers,
or Windows. It is always justified in the absence of any performance data
by “this will improve performance”.
Sigh.
joe
“Tim Roberts” wrote in message news:xxxxx@ntdev…
>> Pavel A wrote:
>>> On 31-Jul-2012 19:12, Tim Roberts wrote:
>>>> There is no such call. During negotiation, there is a property
>>>> request
>>>> that returns the mapped virtual address of the hardware’s pointer
>>>> registers. The Audio Engine service writes those pointer registers
>>>> directly. There are no user/kernel transitions when reading or
>>>> writing
>>>> audio data.
>>> Given this, how can we insist that direct mapping of i/o memory to
>>> usermode is bad?
>>
>> The white paper on WaveRT miniport drivers has a paragraph that
>> addresses this, and talks about hardware design strategies to minimize
>> the risk. For the most part, it dances around the topic.
>>
>> We all know that the danger depends on the cost of an intrusion. In
>> this case, the only cost of a break-in by a malicious process would be
>> to mess up your playback of Taylor Swift’s latest song.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>
> The security aspect of direct i/o space access IMHO is the last
> to worry about. - because no existing Windows product holds
> any hope against malware, as recent findings have shown.
>
> But will bad things happen when power management
> processing isn’t synchronized with access from usermode:
> for example, consider when a PCI device does to D3
> or PCIe link down state, while usermode app keeps
> banging thru a BAR mapping on it?
> And providing sync between the app and driver will
> add complexity, overhead, and even then won’t be 100% reliable.
> What do you think?
>
> Regards,
> – pa
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Pavel A. wrote:
“Tim Roberts” wrote in message news:xxxxx@ntdev…
>> Pavel A wrote:
>>> On 31-Jul-2012 19:12, Tim Roberts wrote:
>>>> There is no such call. During negotiation, there is a property request
>>>> that returns the mapped virtual address of the hardware’s pointer
>>>> registers. The Audio Engine service writes those pointer registers
>>>> directly. There are no user/kernel transitions when reading or writing
>>>> audio data.
>>> Given this, how can we insist that direct mapping of i/o memory to
>>> usermode is bad?
>>
>> The white paper on WaveRT miniport drivers has a paragraph that
>> addresses this, and talks about hardware design strategies to minimize
>> the risk. For the most part, it dances around the topic.
>>
>> We all know that the danger depends on the cost of an intrusion. In
>> this case, the only cost of a break-in by a malicious process would be
>> to mess up your playback of Taylor Swift’s latest song.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>
> The security aspect of direct i/o space access IMHO is the last to worry
> about. - because no existing Windows product holds
> any hope against malware, as recent findings have shown.
>
> But will bad things happen when power management processing isn’t
> synchronized with access from usermode:
> for example, consider when a PCI device does to D3
> or PCIe link down state, while usermode app keeps
> banging thru a BAR mapping on it?
> And providing sync between the app and driver will
> add complexity, overhead, and even then won’t be 100% reliable.
> What do you think?
>
Despite what Tim says. In the WaveRT drivers I’ve written (and the inbox
driver for Intel HD Audio) the audio buffer is still in host memory. The
audio codec then dma’s from this buffer (for playback) and to this
buffer (for recording). The position pointer returned by the hardware
allows the user mode audio engine to know when the data in particular
parts of the buffer can be safely accessed. Power requests during
playback and recording stop the DMA process so there is no issue with
syncing with usermode as it gets informed about the stream state change.
Mike
–
Mike Pumford, Senior Software Engineer
MPC Data Limited
e-mail: xxxxx@mpcdata.com web: www.mpcdata.com
tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601
ddi: +44 (0) 1225 710635
Pavel A. wrote:
But will bad things happen when power management
processing isn’t synchronized with access from usermode:
for example, consider when a PCI device does to D3
or PCIe link down state, while usermode app keeps
banging thru a BAR mapping on it?
Well, it becomes a no-op. The writes go into empty space.
And providing sync between the app and driver will
add complexity, overhead, and even then won’t be 100% reliable.
What do you think?
The Vista Audio Engine now has about 7 years under its belt and has
proven to be extremely reliable. There may be issues with the direct
mapping concept in the general case, but I’m guessing the audio team was
sufficiently aware of the problems to build in whatever hooks were
necessary to participate in the power process.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim, that really depends on the machine. A write to MMIO space that was
backed by a BAR until the device went to D3 will generate a fatal error in
some machines. It all depends on what level of error checking the BIOS
decides to enable.
Now, with that said, the machine that tend to enable this sort of error
checking tend not to have audio. (You couldn’t hear it over the fans, even
it you wanted to.)
Oh, and you’d be guessing wrong if you thought that the audio team sync’s up
with power management at all. They assume that devices only leave the D0
state when the system is leaving S0, and that all audio playback will have
ceased by then.
Jake Oshins
Windows Kernel Team
“Tim Roberts” wrote in message news:xxxxx@ntdev…
Pavel A. wrote:
But will bad things happen when power management
processing isn’t synchronized with access from usermode:
for example, consider when a PCI device does to D3
or PCIe link down state, while usermode app keeps
banging thru a BAR mapping on it?
Well, it becomes a no-op. The writes go into empty space.
And providing sync between the app and driver will
add complexity, overhead, and even then won’t be 100% reliable.
What do you think?
The Vista Audio Engine now has about 7 years under its belt and has
proven to be extremely reliable. There may be issues with the direct
mapping concept in the general case, but I’m guessing the audio team was
sufficiently aware of the problems to build in whatever hooks were
necessary to participate in the power process.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> Oh, and you’d be guessing wrong if you thought that the audio team sync’s up
with power management at all. They assume that devices only leave the D0
state when the system is leaving S0, and that all audio playback will have
ceased by then.
Is it so in Win8’s power management smartness too?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
It’s essentially unchanged from Windows 7. A miniport can interact with
PoFx, but doing that in a way that integrates with the S-IRP and D-IRP
handling in KS is a proposition that’s somewhat too complicated to sum up
here.
Jake Oshins
Windows Kernel Team
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…
Oh, and you’d be guessing wrong if you thought that the audio team sync’s
up
with power management at all. They assume that devices only leave the D0
state when the system is leaving S0, and that all audio playback will have
ceased by then.
Is it so in Win8’s power management smartness too?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com