[wdmaudiodev] Re: WavePCI issue with multiple processors
- From: Ken Cooper <Ken.Cooper@xxxxxxxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Tue, 27 Mar 2007 17:24:01 -0700
Jeff,
Each port pin in WavePci has an instance of an IrpStream object associated
with it. The IrpStream object facilitates all of the streaming IRP helper
functionality for the pin, including queue management, mapping and unmapping.
The IrpStream object contains an internal member variable that keeps track of
the starvation state of the pin. For discussion purposes, call this variable
WasExhausted. This variable is initialized to TRUE when the object is created
(pin/stream create time). As IRPs arrive the IrpStream object performs some
management tasks (creates and initializes a mapping context and sticks the IRP
into a cancellable mapping queue) and then looks at the WasExhausted variable.
If the value of WasExhausted is TRUE, it sets the value of WasExhausted to
FALSE and calls IrpSubmitted on the port pin, which in turn calls
MappingAvailable on the miniport stream.
When GetMapping is called it attempts to get the next previously mapped
mapping. If there are no previously mapped mappings available it grabs the
next available IRP off of the mapping queue. If there is an IRP available it
attempts to map the IRP to obtain a mapping. The bottom line here is that if a
mapping cannot be obtained when you call GetMapping the variable WasExhausted
is set to TRUE (and MappingAvailable is called when the next IRP arrives). It
should be fine to call GetMapping without waiting for a MappingAvailable call.
Note that in the description above there is no mention of pin/stream state
dependencies. MappingAvailable is called in response to IRP arrival, not state
transitions. Unfortunately I don't have easy access to more than a couple
years of change history for the portcls code and, frankly, I simply don't
remember every detail from the Win98/Win2K days so I can't give you a reliable
answer about the behavior differences between Win2K and XP/Vista.
Ken
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Jeff Pages
Sent: Tuesday, March 27, 2007 4:15 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: WavePCI issue with multiple processors
Hi Ken,
Thanks for that information. Is there anything more you can tell me about
calls to MappingAvailable? The current documentation says it should only be
called when a previous call to GetMapping has failed. The call when the
stream is new doesn't happen in Windows 2000, only in XP and later it seems.
It looks like it happens when the stream state changes from KSSTATE_PAUSE to
KSSTATE_ACQUIRE - is this correct?
Also, is it really safe in a multiprocessor environment to keep calling
GetMapping after it has failed, or should I wait until I get a call to
MappingAvailable?
Jeff
----- Original Message -----
From: "Ken Cooper" <Ken.Cooper@xxxxxxxxxxxxx>
To: <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Tuesday, March 27, 2007 3:14 PM
Subject: [wdmaudiodev] Re: WavePCI issue with multiple processors
> 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/
>
>
>
******************
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:
