-----Ursprüngliche Nachricht-----
Von: AI Developer [mailto:developer@xxxxxxxxxxxxxxxx]
Gesendet: Dienstag, 17. August 2010 07:55
An: wdmaudiodev@xxxxxxxxxxxxx
Betreff: [wdmaudiodev] Re: AW: Re: AW: Re: Possible problem
in IPortDMus::Notify and servicegroup dispatching?
Puryear acknowledged it, and provided alternative code. The
original discussion was when this list was on Yahoo groups.
I'm not sure if you can access the group now - as it requires
membership.
X-archive-position: 4925
X-ecartis-version: Ecartis v1.0.0
Sender: wdmaudiodev-bounce@xxxxxxxxxxxxx
Errors-to: wdmaudiodev-bounce@xxxxxxxxxxxxx
X-original-sender: developer@xxxxxxxxxxxxxxxx
Precedence: normal
Reply-To: wdmaudiodev@xxxxxxxxxxxxx
List-help:<mailto:ecartis@xxxxxxxxxxxxx?Subject=help>
List-unsubscribe:
<wdmaudiodev-request@xxxxxxxxxxxxx?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: wdmaudiodev<wdmaudiodev.freelists.org>
X-List-ID: wdmaudiodev<wdmaudiodev.freelists.org>
List-subscribe:<wdmaudiodev-request@xxxxxxxxxxxxx?Subject=subscribe>
List-owner:<mailto:schulz.carsten@xxxxxxx>
List-post:<mailto:wdmaudiodev@xxxxxxxxxxxxx>
List-archive:<//www.freelists.org/archives/wdmaudiodev>
X-list: wdmaudiodev
There is however a (badly formatted version) of the
discussion on freelists. Here is one link:
//www.freelists.org/post/wdmaudiodev/Problem-capturing-mi
di-on-multiprocessor-SMP-XP-machines,2
Hope that helps.
Thanks.
Devendra.
ps: If you need the better formatted version, please email me
off the list, and I'll copy paste from the Yahoo group archive.
On 8/17/10 4:19 AM, Evert van der Poll wrote:
Hi Tobias,
Maybe I wasn't entirely clear.
But would not the race-condition persist?
The MIDI data is returned by calling
IAllocatorMXF::PutMessage(), not
by the return value from the function. That is right.
But if the queue is empty, the call to IMXF::PutMessage()
will return
to PortCls without having submitted new data. PortCls will only call
IAllocatorMXF::PutMessage() after it has processed all
previous data.
So in this last call it is safe to set your "not running anymore"
flag, knowing that you already emptied your queue in the
previous call
and that there is not going to be any processing on
PortCls's side since there is no new data.
There is no race-condition in this scenario.
I was still wondering if it is safe to call PutMessage on the
Allocator of the IPortDMus within The PutMessage() of the
render-stream for example.
Actually I don't use a spinlock on my capture stream. If you look
closely at the DDK sample you will see that it also doesn't use a
spinlock there. The call to
SourceEvtsToPort() from the
PutMessageLocked() function is actually bogus. You won't call this
from your DPC because that is handling your render stream.
The capture
stream is entirely driven by PortCls.
The only place where I call IAllocatorMXF::PutMessage()
while holding
a spinlock is on my render stream. This looks safe to me.
You're only
recycling a used event. There is not going to be any
processing on it
on PortCls's side.
Regards,
Evert
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx]On Behalf Of
Tobias Erichsen
Sent: Monday, August 16, 2010 2:00 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] AW: Re: AW: Re: Possible problem in
IPortDMus::Notify and servicegroup dispatching?
Hi Evert,
This is indeed an annoying problem and probably easy to fix if you
have the source code of PortCls. But somehow I doubt
that is going to happen. Is PortCls even supported still?
I know that
Microsoft pulled the plug for DirectMusic some time ago.
AFAIK the PortCls is still part of the complete
audio-framework up to
Windows 7, so I hope it is still supported ;-)
The problem is not with IAllocatorMXF::PutMessage() or
IAllocatorMXF::GetMessage(). My Syser aided investigation
showed that
the deadlock occurs AFTER you return to PortCls from
IMXF::PutMessage() on a capture filter.
That was also what I figured, but apart from this current
freezing-issue, I was still wondering if it is safe to call
PutMessage
on the Allocator of the IPortDMus within The PutMessage() of the
render-stream for example.
It is done in the sample, so I would consider it safe (but
we all know
that there have been locking-issues in early versions of
the sample -
hence the split into PutMessage and PutMessageLocked ;-)
And the same question goes for the capture-stream: can I call
GetMessage and PutMessage on the Allocator of the IPortDMus while
holding my private locks to secure my internal fifo?
My guess about what happens is this: IMXF::PutMessage() is
called on
a
capture filter to retrieve MIDI data from it. It is a
response to calling IPortDMus::Notify() on your capture
port. PortCls
will continue to call IMXF::PutMessage() until that
function returns NULL, meaning there is no more data.
I thought that the PutMessage returns an NTSTATUS - what
result-code
would tell the PortCls to call me again?
The processing that PortCls does after receiving data from
IMXF::PutMessage() needs to acquire two spinlocks. About the same
time IPortDMus::Notify() needs to acquire the same two
spinlocks but
in reversed order; a classic deadlock scenario.
The important thing in the above sentence is that, if there is no
data
returned from IMXF::PutMessage() there will be no
processing and hence no need to acquire the spinlocks.
That is why my
solution will work; because there will be no new
IPortDMus::Notify() call until IMXF::PutMessage() returns NULL.
But would not the race-condition persist? When the last
thing you do
in your PutMessage method is to reset a state-variable to
"not running
anymore", you return and at that point PortCls will do the
PostProcessing with the necessity to lock ist Spins and at the same
time the place where you call the Notify() will also know that the
"not running anymore" is true and issue a Notify?
However, I tested this extensively with MidiTest (another one of
those
indispensible tools ;))
I really love this tool - used it to test my driver (together with
MIDI-OX) extensively.
So, don't worry!
Unfortunately I'm the worrying kind ;-)
Tobias
******************
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/
