[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
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.
Jeff
******************
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/
Other related posts:
