Thank you Eugene for your idea. I already did some first test. In case of my multi - waveminiport implementation restricting everything to CPU 0 is not very good for performance and increases the risc of glitches. Perhaps each miniport should use a different CPU (if available), but would this still fix the issue/problem/bug ? When should the affinity restriction be canceled ? at SetState(KSSTATE_STOP) ? I don't think that there is a multi-core related bug in WavePCI sample code, so this would mean that this fix avoids a problem somewhere in a upper kernel or user space layer of the audio stack. Or do you have another explanation why this should/could fix the issue ? Perhaps related to the fact that you need a KeReleaseSpinLock before calling PortStream->GetMapping or PortStream->ReleaseMapping ? Thank you again and best regards. Markus. 2012/2/20 Eugene Muzychenko <eugene@xxxxxxxxxxxxxx> > Hello Markus, > > > But changing driver architecture or implementing my own streaming > interface > > is not really a solution that I expected to do.... > > The only solution I have found for PortCls is to restrict affinity of > the thread providing IOCTL_KS_READ_STREAM/IOCTL_KS_WRITE_STREAM IRPs > to a single CPU (for example, CPU 0). Processing these IRPs, PortCls > calls MappingAvailable so you can insert affinity restriction code > into this function. Don't forget to save thread ID to an internal > list/array to avoid calling affinity set functions every time. > > Regards, > Eugene > > ****************** > > 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/ > >