or an example of a driver that implements its own DMA-channel object, see the SB16 sample audio adapter in the Windows DDK. If the constant OVERRIDE_DMA_CHANNEL is defined to be TRUE, the conditional compilation statements in the source code enable the implementation of a proprietary IDmaChannel object, which the driver uses in place of the default IDmaChannel object from the IPortWaveCyclic::NewXxxDmaChannel call.

It is becoming increasingly common for a PC to contain more than 4 gigabytes of RAM, and on those systems it is possible to have mappings that are located higher than 4 GB in physical memory (in both the 64-bit CPU case and the x86 PAE case). To achieve the best performance on these machines, IHVs should create devices that support 64-bit addressing, otherwise data copying in software is required. This has historically been the case with devices that require 24-bit addressing on systems with more than 16 MB of RAM. Devices should use WaveCyclic instead of WavePci if they cannot read from or write to anywhere in physical memory. It is acceptable for a driver to make this decision at StartDevice time.

Originally Posted by Russ The SB16 sample's IDMAChannel implementation appears to just call the base class implementation of each function and does not really implement any of the functionality itself. In any case it should prove useful to show how to get an initial IDMAChannel object to work with, and then you should only need to implement some of the functions (like (I assume) AllocateBuffer) and call the base class implementation for the rest.

I uploaded the first version of the sample implementation. You can review it at http://home.arcor.de/infolchinger/CDmaChannel.cpp and http://home.arcor.de/infolchinger/CDmaChannel.h

I did some quick tests on a WinXP 1GB machine and it appears to do what it should. Tonight I will test it on a 4GB Win 7 machine. This will be the moment of truth since on this system, the current driver version will always fail with random noise. If the physical address of CDmaChannel is below 2G there, chances are that we soon have a driver that will work on all systems regardless of available memory.

Some notes about the source: It is written in C++ and brings its own new/delete operator. If your driver already defines operator new and operator delete, you can just delete the ones of the CDmaChannel class. The class itself can be instantiated by calling CDmaChannel::Create or (if you use C) by calling CreateCDmaChannel. Parameters are size in bytes and highest acceptable physical address. Therefore, it should be possible to replace NewMasterDmaChannel by a call to CDmaChannel::Create and return this object instead of the one created by NewMasterDmaChannel.

Results of the Win 7 Tests: Returned physical address was good on several tries.

Originally Posted by RPGWiZaRD It's actually working? If so you've just extended kX driver's life at least another 10+ years (I hope). ^^