[wdmaudiodev] AW: Re: AW: Re: AW: Re: Possible problem in IPortDMus::Notify and servicegroup dispatching?

  • From: "Tobias Erichsen" <t.erichsen@xxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 17 Aug 2010 08:13:50 +0200

Hi Evert,

thanks again for your invaluable feedback...

> 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.

You are right of course - I have changed my code correspondingly
and the first results seem promising :-)

Though this only works under one assumption:

The ::PutMessage() on the drivers capture-stream must be called at
least one additional time by PortCls for the clearing to work,
otherwise we will get into a starvation situation since the producer
will never again call ::Notify()

So anyone from Microsoft listening in on this conversation?

Is this behaviour inherent in all current PortCls implementations
for the various OSs (XP -> W7, 32bit & 64bit)?
And can one expect this behaviour to persist in future updates?

Best regards,


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


Other related posts: