[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 15:44:42 +0000

  *   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%7Cd5618e4388564013efff08d87cd828c4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637396615168314188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LnhdlnwgKnzEtzP6HC93eI1LDT0G5fJNAHeDQU3%2ByqM%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: