[wdmaudiodev] Re: [EXTERNAL] Understanding IMiniportWaveRtStreamNotification::RegisterNotificationEvent
- From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Fri, 30 Oct 2020 16:45:53 +0000
Who consumes the data that Windows writes to you? Do they have a clock?
From: wdmaudiodev@xxxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxxx>
Sent: Friday, October 30, 2020 9:26 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: [EXTERNAL] Understanding
IMiniportWaveRtStreamNotification::RegisterNotificationEvent
Please don’t do this.
I'd rather go with the prevailing wisdom and do it 'properly', vs. produce
another crappy, battery-draining Windows driver. So, OK, no timer.
SYSVAD is the only example of this that I have, and it says (paraphrasing) "in
a real driver, you wouldn't use a timer like we show here; your DMA hardware
and position registers would handle ...".
My driver is virtual, though, so there is no hardware. It just copies packets
from RENDER[1] to CAPTURE, without buffering.
I could create a worker thread that waits on both render-data-ready and
capture-buffer-available events. I don't have any driver-specific examples of
this, but I've done this in desktop apps in the past.
Any suggestions/advice? Any insight on the SetWritePacket/SetReadPacket
question?
--S
[1] Or, if I can get a custom interface working, copy data
passed-from-app-to-driver via backchannel
On 10/30/20 8:44 AM, Matthew van Eerde (Redacted sender Matthew.van.Eerde for
DMARC) wrote:
* I have a timer function that monitors this
Please don’t do this.
From: wdmaudiodev@xxxxxxxxxxxxxx<
mailto:wdmaudiodev@xxxxxxxxxxxxxx>
Sent: Friday, October 30, 2020 6:31 AM
To: wdmaudiodev@xxxxxxxxxxxxx<
mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [EXTERNAL] [wdmaudiodev] Understanding
IMiniportWaveRtStreamNotification::RegisterNotificationEvent
Hi,
I was a bit confused by the function of the
IMiniportWaveRtOutputStream::SetWritePacket and
IMiniportWaveRtInputStream::SetReadPacket methods, and the KEVENT passed into
RegisterNotificationEvent.
If I understand it correctly, AllocateBufferWithNotification gets called with
notificationCount=2, and a buffer large enough for two 'packets'. Packets seem
to be sized to contain about 1/100 sec worth of audio frames.
RegisterNotificationEvent gets called with a single (in my case) event.
In the RENDER case, SetWritePacket(n, ...) is called when the OS has finished
copying packet <n> into whichever half of the buffer. I have a timer function
that monitors this, and transfers the packet to hardware (let's say). To let
the OS know that packet <n> has been processed (i.e., that packet in the buffer
is available), I call KeSetEvent(pNotificationEvent, 0, FALSE).
So this part isn't clear to me:
...kernel event that must be notified as DMA progresses. Depending on the
notification count parameter used with
AllocateBufferWithNotification<
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdrivers%2Fddi%2Fhdaudio%2Fnc-hdaudio-pallocate_dma_buffer_with_notification&data=04%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbcad1538d35f45962bf608d87cf07b3d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637396719628584161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=z9KlRSi4n2Em0MvKULfB8s%2FdiSeKhoVX9A%2B6neTWveI%3D&reserved=0>,
the registered event is signaled __one or two times__ for every time that the
DMA passes through the audio buffer.
I expected there to be two calls to RegisterNotificationEvent, and thus two
KEVENT objects at any given time (one for each packet in the buffer). Instead,
I only see one getting added. The doc quote above seems to suggest that a
single event has to be set TWICE (or maybe set once, then the OS clears, then
set again)? I've looked at the KEVENT struct and related APIs, but I'm still
confused. Is this event supposed to signify "Buffer Complete" or "Packet
Complete"?
In the CAPTURE case, it looks like things are reversed. The OS calls
SetReadPacket to query the driver about which packet is available for reading
(transferring to client). RegisterNotificationEvent is getting called, so I
think the same (single) event is SET/CLEARED? by the OS to signal ME that it
has finished transferring data out of a packet, and that packet is available
for DMA again.
Thanks in advance for any and all help. :-)
Other related posts:
