[wdmaudiodev] Re: More Kernel Streaming confusion.

  • From: Max K <xaseriii@xxxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Sun, 23 Jun 2013 12:10:21 +0200

Hi Jeff,

thanks for your mail, it all got a bit clearer now. I used to look more at the 
Dmus side of KS where things didn't seem to fit the purpose, but looking at the 
way a wave audio card works the concept makes more sense.

I guess I will keep trying a bit to get custom Pins working and see where I get 


> From: barefeet@xxxxxxxxxxxxxx
> To: wdmaudiodev@xxxxxxxxxxxxx
> Subject: [wdmaudiodev] Re: More Kernel Streaming confusion.
> Date: Sun, 23 Jun 2013 10:25:51 +1000
> Hi Max,
> PortCls is principally used to represent audio devices that use DMA to 
> transfer the audio to and from the hardware. In that respect, the drivers 
> don't get involved in the actual transfer of audio (with one exception), as 
> the hardware's DMA engine takes care of that, so try not to think of audio 
> "passing through" any of it.
> A PortCls driver has two components, a wave port and a topology port. The 
> wave port is primarily responsible for setting up the DMA parameters, 
> setting sampling rates and bit depths, and starting and stopping the 
> streams. There are currently three flavours of wave ports - WaveCyclic (the 
> oldest), WavePCI and WaveRT. WaveCyclic requires the driver to copy the 
> audio data to and from the kernel-space DMA buffers (this is the exception I 
> mentioned above), whereas WavePCI and WaveRT set up DMA transfers directly 
> to and from user-space buffers. WaveRT is the preferred model but is only 
> supported on Vista and later systems.
> The topology port is where the hardware's audio controls are represented, 
> and this is where the nodes come in. Each node represents one of the 
> hardware's physical controls, such as faders, mutes, multiplexers, mixers 
> and peak meters. Note that these are hardware controls - the driver's 
> topology port doesn't (or shouldn't) go anywhere near the audio data. The 
> controls are adjusted using property set calls, which are typically used to 
> write to or read from hardware registers. The driver creates a 
> PCFILTER_DESCRIPTOR structure that describes how the various controls are 
> connected together - this is where the pins, nodes and connections come in.
> The topology port provides the back-end functionality that applications see 
> through the Mixer API or the corresponding Core Audio interfaces such as 
> IDeviceTopology, although each of these APIs has a different way of 
> describing the topology (more confusion!).
> Windows provides the top-level wave port and topology port objects, which 
> communicate with driver-supplied hardware-specific miniports. Like much 
> kernel code, it's hard to see the forest for the trees, and the best way to 
> learn is to actually write a driver for some hardware, using one of the 
> sample drivers as a starting point.
> I hope that's of some help to you. Have a look at the "Introduction to Port 
> Class" section of the WDK documentation, particularly the diagrams. The 
> documentation does seem to lack a beginner's entry point and can be rather 
> daunting and confusing when you don't have a clear mental picture of how it 
> all hangs together, and a lot of it refers to the pre-Vista systems which 
> got superseded by the later OS's audio engine and endpoint-centric 
> architecture. I think writing a driver (preferably for some real hardware) 
> and poking around in it with windbg is about the only way to get a good 
> handle on how it all works.
> Jeff
> From: Max K
> Sent: Sunday, June 23, 2013 5:01 AM
> To: wdmaudiodev@xxxxxxxxxxxxx
> Subject: [wdmaudiodev] More Kernel Streaming confusion.
> Hi,
> over the time, I got more and more insight in KS, but worryingly, things 
> didn't become clearer but more confusing. It would be great if somebody 
> could give a short explanation to the questions I have.
> If I'm correct, PortCL is just a "sub-framework" to make driver construction 
> easier, by reducing the amount of ks code that needs to be written.
> However does this mean that I am also restricted in KS functionality by 
> using portCL?
> For example, I read on MSDN that usually Pins are instantiated using 
> createFile and interfaces with using DeviceIoControl, however I don't see 
> how to properly implement a custom pin with a generic datarange in a portcl 
> minidriver (its even worse documented in the MSDN than MIDI).
> Then there is the question: what do I need nodes and connections for? It 
> would make perfectly sense, if the data was passed along the connections and 
> each node hat a data processing function, but the only reason sample driver 
> seem to have nodes for are to handle Property Requests.
> Data isn't passed through the filter, its passed to a stream that is 
> connected to the pin which either stores it internally or in the Miniport. 
> What happens there is completely up to the miniport.
> It may well be that I'm talking nonsense here but that's how I currently 
> perceive Kernel Streaming.
> Regards,
> Max 
> ******************
> WDMAUDIODEV addresses:
> Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
> Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
> Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
> Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
> http://www.wdmaudiodev.com/

Other related posts: