Not sure if this is the cause but. Skype does very strange things when it is run on a machine that is enabled for kernel debugging. If your machine is in that state, I would change that single variable and see if by chance it solves your issue. From what I have seen in the past, a machine capable of being debugged is virtually unusable for more than a few minutes if Skype is running. From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Basileios Bu Sent: Friday, June 08, 2012 2:07 PM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Strange Delay with MIDI Filter Creation Times (AVStream) Hello, We have a high speed USB audio device which exposes audio in(4)/out(4) and MIDI in(1)/out(1), and we use AVStream as a driver model, which creates 4 KS filters, 2 audio, and 2 MIDI. I am experiencing a strange issue with the creation time of one of our MIDI filters when Skype is running in the background (even when its told not to target our device), only on Windows XP. When Skype is not executing, there is no delay; I create my filter factories without incident, and very soon after PostStart, our filters are created by the system. However, when Skype is executing in the background (even when told never to address our devices), there is a delay (5-7 seconds!) between creation of the audio/MIDI input filters and the remaining MIDI output filter. Even if I don't create the audio filter factories, the aforementioned delay remains with respect to the last MIDI filter. I see this delay in the timestamps of WPP traces in my filter creation calls (the last such filter created is long delayed when Skype is in the background). I see quite clearly in KS Studio that under the category "KSCATEGORY_AUDIO_DEVICE" that one instance out of four lags in creation time (which I assume to be the MIDI output instance in the general case in which I create all 4 filters). Note that for all cases when I create my 4 filter factories the DDI KsCreateFilterFactory returns success, as does KsFilterFactorySetDeviceClassesState. I tried moving filter factory creation and enabling to AVStrMiniDevicePostStart from AVStrMiniDeviceStart because the docs say that IoRegisterDeviceInterface (which is done prior to the creation of the filter factories) must be done in the context of a system thread, which AVStrMiniDevicePostStart seems to guarantee, but that had no effect. The filters are created in the context of work items, which are a limited resource, and I tried increasing the number of work items via the registry, but this had no effect. Now there were some topology differences between the MS MIDI filters and our MIDI filters, but even when I applied most of the differences, there was no effect. For example, I used the category "KSCATEGORY_AUDIO" instead of "KSNODETYPE_SPEAKER/KSNODETYPE_LINE_CONNECTOR", and removed our internal sum nodes, but there was no effect whatsoever, so it does not seem (to me, at least) to be a topology issue. On significant difference which I could not test is that MS uses just one filter with multiple pin factories, while the we have multiple filters with two pins factories each. This is not a trivial change to implement at this point, and note that the input and output audio filter creation times are *not* similarly delayed, at least as far as I can tell from WPP trace timestamps. Would anyone have any idea as to the cause? Is there any way to speed up filter creation? Am I possibly missing some INF registry entries? Without Skype, there are no large delays whatsoever. Very Strange. Thank you for any help or insight.