You are not logged in. Please login or register.
RME User Forum → FireWire & USB series → Has somebody DPC latency due to restart with Babyface?
I have this problem if pc is restarted. If shutdown and open again it's ok.
And today I found the exact problem. After restart pc get gradually go up and down spikes only one cpu core.
And I tried all usb component exept my "Babyface". When I tried only "Babyface" voilà! Cpu spikes are gone.
I'm asking my question again: Has somebady DPC latency due to retart with Babyface?
BTW I'm using Windows 7 Ultimate 64bir SP1.
"Up and down spikes" of CPU load?
Did you set up a sample buffer of 48/96/192 samples by chance?
This is what I get from restart and reconnect babyface.
[img align=C]https://dl-web.dropbox.com/get/Photos/Sample%20Album/babyface.gif?w=d966ab6d[/img]
"Up and down spikes" of CPU load?
Did you set up a sample buffer of 48/96/192 samples by chance?
No I don't and my previously post represent the problem.
Well, once you write about CPU load then you ask about DPC latencies. This is a bit confusing.
Well, once you write about CPU load then you ask about DPC latencies. This is a bit confusing.
Same issue as this: http://www.rme-audio.de/forum/viewtopic.php?id=11120
It's not a DPC issue, it's a cycling CPU usage that alternates between ~20% and ~40% on a single core, in a very regular fashion. When audio is playing it switches between ~0% and ~100% at a much faster rate. Unplugging the unit and plugging it back into the port fixes the issue until the computer is restarted.
Resource Monitor says it's due to deferred procedure calls and/or interrupt service routines. LatencyMon suggests USBPORT.sys as the possible culprit, having the highest DPC and ISR counts of any driver. Again it's not a DPC issue per se, since there are no spikes above 100 microseconds and my overall latency stays below 200.
I've done some research and it seems like USB audio devices in general cause this issue in certain cases. A hotfix was produced by Microsoft but it was apparently included in SP1, which I already have. I'm guessing the problem here is with the Microsoft USB driver, or with the way the Babyface communicates with it (firmware/driver issue). You guys would know better than me obviously but I'm just putting some thoughts out there to get the ball rolling.
Please consider possible ways to fix this that don't include: clean boots, reinstalling the USB controllers in the device manager, disabling power saving features, trying driver 0.966 or 0.979, switching USB ports, or disconnecting USB devices.
Here you can see the consequence of uninstalling the USB Enhanced Host Controllers. The CPU usage drops to 0%, and then once Windows automatically reinstalls the devices, the same pattern of CPU usage is observed. So maybe it's a problem that occurs during the loading of the drivers for the controllers?
Well, once you write about CPU load then you ask about DPC latencies. This is a bit confusing.
Actually when the CPU spikes occurs on my system simultaneously suffers from DPC latency.
Timur wrote:Well, once you write about CPU load then you ask about DPC latencies. This is a bit confusing.
Same issue as this: http://www.rme-audio.de/forum/viewtopic.php?id=11120
It's not a DPC issue, it's a cycling CPU usage that alternates between ~20% and ~40% on a single core, in a very regular fashion. When audio is playing it switches between ~0% and ~100% at a much faster rate. Unplugging the unit and plugging it back into the port fixes the issue until the computer is restarted.
Resource Monitor says it's due to deferred procedure calls and/or interrupt service routines. LatencyMon suggests USBPORT.sys as the possible culprit, having the highest DPC and ISR counts of any driver. Again it's not a DPC issue per se, since there are no spikes above 100 microseconds and my overall latency stays below 200.
I've done some research and it seems like USB audio devices in general cause this issue in certain cases. A hotfix was produced by Microsoft but it was apparently included in SP1, which I already have. I'm guessing the problem here is with the Microsoft USB driver, or with the way the Babyface communicates with it (firmware/driver issue). You guys would know better than me obviously but I'm just putting some thoughts out there to get the ball rolling.
Please consider possible ways to fix this that don't include: clean boots, reinstalling the USB controllers in the device manager, disabling power saving features, trying driver 0.966 or 0.979, switching USB ports, or disconnecting USB devices.
Har, if you check Windows Update you'll see a fix for USBPORT.sys issue. I alredy updated my system but problem isn't solved with that fix. And you say "it's not DPC issue" but it's exaggerate the crackles on ASIO and audio playing on OS.
Har, if you check Windows Update you'll see a fix for USBPORT.sys issue. I alredy updated my system but problem isn't solved with that fix. And you say "it's not DPC issue" but it's exaggerate the crackles on ASIO and audio playing on OS.
You're right and I have it to, but yeah it doesn't affect the issue.
Do you have any link to the pre-SP1 hotfix?
This is the driver version you should be running currently: (6.1.7601.)17586. It was supposed to be included in SP1, but failed to install and was again published as a "Recommended" update on Mai 11th. It may fail to install on first try and need a reboot to get a second try. You can also download it manually, where again it may fail to install. At least one user on the web reported reproducible Blue Screens with this update.
What USB controller (brand version) do you use? You can try to exchange whatever USB interface/driver is shown with the "Standard USB to PCI Host Controller". Does it make a difference?
As far as I understood this is not a DPC issue, but an issue with the USB port. This in turn causes increased CPU load and DPC Latencies, but not increased DPC Durations. I've seen the latter just two weeks ago with a Firewire port.
Does the Fireface settings count USB errors? If yes, which type (there are two counters)?
Do you have any link to the pre-SP1 hotfix?
http://support.microsoft.com/kb/981214
This is the driver version you should be running currently: (6.1.7601.)17586. It was supposed to be included in SP1, but failed to install and was again published as a "Recommended" update on Mai 11th. It may fail to install on first try and need a reboot to get a second try. You can also download it manually, where again it may fail to install. At least one user on the web reported reproducible Blue Screens with this update.
Yep, that's the version I have.
What USB controller (brand version) do you use? You can try to exchange whatever USB interface/driver is shown with the "Standard USB to PCI Host Controller". Does it make a difference?
I'm using a board with the Intel ICH10 controller (not sure if you need me to be more specific than that). I did try changing the driver to the standard one, but the same issue persisted.
As far as I understood this is not a DPC issue, but an issue with the USB port. This in turn causes increased CPU load and DPC Latencies, but not increased DPC Durations. I've seen the latter just two weeks ago with a Firewire port.
That indeed seems to be the case.
Does the Fireface settings count USB errors? If yes, which type (there are two counters)?
0/0 on my end.
http://support.microsoft.com/kb/810876
I found this article that might explain why the CPU usage appears to be alternating like that, not that it explains what's causing it or anything.
Trying firmware beta 183 didn't do much, but I noticed if I quit TotalMix FX the CPU usage seems to be reduced by ~10-20%. I'm starting to think any apparent difference in CPU usage is just the activity going into or out of sync with the task manager's polling rate though (as linked above).
The KB article you linked to specifically points to using a root hub with audio. What happens when you put an USB hub in between?
Also try uninstalling the Mai 11th update going back to 16xyz version drivers (pre SP1). Does that make a difference?
Don't have a USB hub to test with (unless I misunderstood what you meant?).
Tried uninstalling the update, and the previous drivers have the same issue. Maybe if I tried a pre-179 firmware, and some older drivers? Don't know where to grab those though.
I reproduced the issue and investigate it right now.
Timur seemed to have found the reason. We are now trying to fix this in our driver/firmware. Stay tuned.
Great! Thank you so much guys.
Eagerly!!
This problem, which seems to be isolated to the Babyface and Windows 7 SP1, has been fixed in two ways:
- The new firmware 184 fixes it if you are on a driver version below 0.981
https://archiv.rme-audio.de/download/fu … in_rc1.zip
- The new driver 0.981 fixes it regardless of the firmware version
https://archiv.rme-audio.de/download/usb_win_0981.zip
Working perfectly here, thank you very much.
Yep! it's also solved on my PC.
And BTW Why TotalMix FX Assign feature limited to only AN1/2, PH3/4 and AS1/2 channels?
Is that restricted to hardware or software ?
Mentioned in the manual. Other assignments would be missing when changing to higher sample rates, screwing up everything.
Ok, thanks.
I've dig in the manual but couldn't see that detail.
Exactly where it belongs. Page 47, last sentence.
This problem, which seems to be isolated to the Babyface and Windows 7 SP1, has been fixed in two ways:
- The new firmware 184 fixes it if you are on a driver version below 0.981
https://archiv.rme-audio.de/download/fu … in_rc1.zip
- The new driver 0.981 fixes it regardless of the firmware version
Hi There,
After the most recent update (Driver 1.024 and Firmware 203, I’m still experiencing these issues with USB spikes.
System: Windows 7 64Bit SP1, Dell XPS 8300, i7 2600k, 16GB RAM, Cubase 6.5.4.
Forget about Cubase, I can’t even listen to music on Windows Media Player!
Any advice/help would be much appreciated.
Driver 1.024 is not the most recent update, and I wonder what issues you refer to exactly. Usual DPC spikes are not part of this thread.
RME User Forum → FireWire & USB series → Has somebody DPC latency due to restart with Babyface?
Powered by PunBB, supported by Informer Technologies, Inc.