[wdmaudiodev] Re: WavePCI issue with multiple processors
- From: Ken Cooper <Ken.Cooper@xxxxxxxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Mon, 26 Mar 2007 22:14:33 -0700
MappingAvailable is called in two circumstances. The first case is when a new
streaming irp arrives. After the IRP is added to the mapping queue
MappingAvailable is called if the driver is currently starved (the stream is
new or the previous call to GetMapping failed). The second case is in response
to setting the pin position via position property.
The lock issue across GetMapping and ReleaseMapping has been complicated since
the WavePci port was written back in the Win98 days. Unfortunately, if you
attempt to hold a spinlock for your mapping list when you call these routines
you'll likely deadlock with the spinlock that portcls uses to protect access to
it's mapping and unmapping queues.
I don't have the code in front of me at the moment but I'll take a closer look
tomorrow at the portcls and WDK sample code and respond with a little more
detail.
Incidentally, portcls doesn't care at all about your tag values other than that
the outstanding tags at any given moment be unique. They can be monotonically
increasing if you like, or they could be addresses into list of mappings. It's
up to you.
Ken
________________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx [wdmaudiodev-bounce@xxxxxxxxxxxxx] On
Behalf Of Jeff Pages [jeff@xxxxxxxxxxxxxxxx]
Sent: Monday, March 26, 2007 6:58 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: WavePCI issue with multiple processors
Hi Eugene,
> A probability of that a new mapping becomes available exactly within
> this window, is almost zero.
You're right, of course. I was thinking I had to reacquire my spin lock
after the unsuccessful call to GetMapping, but looking at it now, that's not
necessary, and I can just call InterlockedDecrement on my InAcquisitionLoop
variable and exit.
> 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.
For this particular application, I'm using the Vista Core Audio API in
exclusive mode, and this was when some of the wrinkles in my WavePCI drivers
started showing up. I'm now using your suggestion with the interlocked
InAcquisitionLoop variable and so far it's all hanging in there!
Thanks for your help.
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/
******************
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:
