Hello Jeff, > 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. Yes, I think too that AC97 driver has a bug in that part. >> Another way is to use a "who first calls" technique. > 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. A probability of that a new mapping becomes available exactly within this window, is almost zero. > In this case the mapping would sit there until the next Service > call, increasing the likelihood of a hardware buffer underrun in > that time. It is not necessary to acquire mappings only from the Service call. You can ask for new mappings as often as you want. > I suppose I could use another interlocked flag, > MappingAvailableCalled, that could send it round the loop one more > time if set. Of course, it will help in such rare situation. But Windows internal delays and overheads are MUCH MUCH more than this window duration. So you cannot perceptibly gain by that. > So the documentation is wrong. Can it not be made right? MS documentation has some parts that are wrong and/or unclear. Many pages are not revised within several years. So it is not enough to rely on a documentation only :( > 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. In your case, it is not quite important will MappingAvailable be called only if a last GetMapping was failed or if it was succeeded. It does not serialize mapping acquisitions without your own efforts. And a well-optimized driver itself cannot guarantee that all Windows audio subsystems will function quickly and reliably. Even DirectSound with hardware buffers introduces a significant overhead and software buffers and/or MME introduce much more overhead. So you can achieve a reproducible high performance only if your well-optimized application uses your well-optimized audio driver directly via its wave/topology interfaces. Regards, Eugene ****************** 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/