Hi Evert Unfortunately I have been too optimistic. My XP-system froze again - this time after about half an hour. 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 ::PutMessage(). 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 miniport-port/stream 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, 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/