Hi Eugene, Thanks for your response to my question.
It is not necessary to serialize GetMapping calls. You must serialize tag acquisitions only. If a next GetMapping call fails, you can simply leave a last acquired tag unused. Tags are required to be monotonous but not contiguous.
Looking at the AC97 sample code, though, at the point where GetMapping is called, if two processors reach that point at the same time (which they can do because no spin locks can be held at that moment), it's anyone's guess as to which one gets the first block of data and which one gets the second. How do I definitively place them in the dma scatter-gather list in the correct order?
Also, how do I guarantee that the tags are monotonous? The first processor allocated a tag may be sidetracked by a hardware interrupt or something after releasing the driver's spin lock, allowing the second processor to get the next tag in sequence and call GetMapping before the first one does.
As far as I can see, in that window either side of the call to GetMapping, where the driver's spin lock is not held, all bets are off unless calls to GetMapping are strictly serialised.
Another way is to use a "who first calls" technique. If several processors try to simultaneously acquire mappings for a stream, it is not necessary to serialize these calls, it is enough to allow only one of them to enter a mapping acquisition loop and to skip it on others. To implement this technique, you could use a variable like "InAcquisitionLoop" and InterlockedExchange to indicate when the loop is entered/leaved.
That would work, except there's a window between the point where GetMapping fails and the InAcquisitionLoop variable is set to false, in which a call to MappingAvailable will be ignored. In this case the mapping would sit there until the next Service call, increasing the likelihood of a hardware buffer underrun in that time. I suppose I could use another interlocked flag, MappingAvailableCalled, that could send it round the loop one more time if set. Hmm...
portcls calls MappingAvailable in response to IOCTL_KS_READ_STREAM and IOCTL_KS_READ_STREAM IRPs. As documented, it should notify you only if a last GetMapping call was failed but does not always check this condition.
So the documentation is wrong. Can it not be made right?The system I'm working on has sixteen simulaneous audio capture streams happening, and is doing some pretty heavy work on each of the streams in the application code, so I need to optimise the driver efficiency as much as possible while not leaving any possibility of it getting itself tangled up. I could do that if the MappingAvailable mechanism worked strictly as documented, or perhaps even if its anomolous behaviour could be tied down to a specific set of circumstances.
The problem I have is that if I base my driver on what the system appears to do, rather than on what the documentation says, I have no guarantee that it will still work correctly when the next service pack or QFE comes out, or even that it will still work on a different set of hardware.
****************** 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 URL to WDMAUDIODEV page: http://www.wdmaudiodev.com/