[wdmaudiodev] Re: WavePCI issue with multiple processors

  • From: "Jeff Pages" <barefeet@xxxxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Mon, 26 Mar 2007 23:34:17 +1000

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

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


Other related posts: