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

  • From: "Tobias Erichsen" <erichsen@xxxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 17 Aug 2010 13:01:11 +0200

Hi Evert

Unfortunately I have been too optimistic.  My XP-system froze again -
this time after about half an

I'm pretty sure that with your proposed changes implemented I do not
call ::Notify on my
capture-stream's service-group while a the dpc executing the
"SourceEvtsToPort" on this
service-group is actually doing things like ::GetMessage() or

Either I did not implement your changes well enough, or there is still a
locking issue between
different streams - currently I have seperate service-groups for each
and also the "InNotify" is per miniport-port - is this wrong to do?  

Should I have only one service-group for all of my midi-ports and only
one "InNotify" variable
to secure the Notify-calls for all ports at once?  

If that is the case, how can I be sure that this design will not fail if
there are additional
other midiport-drivers (for a usb-midi-device for example) active on the
system and together
they freeze the system?

> I noticed I made a mistake. I used IAllocatorMXF and IMXF as if it
were the same thing, but it's not.
> IMXF is the interface your stream exposes to PortCls while
IAllocatorMXF only handles the pool of events.
> But I guess you still understood what I was saying.

Yes - that's correct - as I based my design on the DMusUart-sample, most
of the specifics
where there already...

>> 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()

> How could it work otherwise? How else is PortCls to know that it has
retrieved all the data?

The DMusUart sample loops as long as there is something in the
software-fifo, calling ::GetMessage()
and ::PutMessage as many times as it needs to deplete the software-fifo.

When it returns, the software-fifo is empty (up to this point, this
might change with the next
"interrupt" though, but then we just call ::Notify() to dispatch the
next iteration of the retrieval
loop again)

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:

  • » [wdmaudiodev] AW: Re: AW: Re: AW: Re: AW: Re: Possible problem in IPortDMus::Notify and servicegroup dispatching? - Tobias Erichsen