Issues with dv7-3000 as a DAW

I'm posting this to find out if anyone has had similar issues...hopefully they have so I can finally pinpoint the problem and put it to rest.

I'm attempting to use a dv7-3000 running win764 with a TC Electronic Studio Konnekt 48 firewire audio interface, but I'm not having much luck. Basically, I see the interface lose sync and regain sync every few seconds. Sometimes, it loses sync for up to a minute, but then regains it. With the loss of sync, I also see have the cursor freeze momentarily.

Now, I know this seems device specific, but I can assure you I have done some testing to rule that out.

The device fails with the same or similar issue when:

*I use the onboard 1394a port with the jmicron driver, win7 stock driver, or win7 stock driver in legacy mode.

*I do the above in win7 32 bit or 64 bit, with any combo of device drivers from the device manufacturer at any buffer setting

*I use the intel chipset drivers, both current and previous.

*I use stock chipset drivers.

*I use the most recent and previous intel matrix drivers

*I use the most recent and previous BIOS

*I use a SIIG 1394a TI based or Best Connectivity TI expresscard with any driver

*All unnecessary hardware (wlan, onboard firewire, onboard usb, ethernet, dvdrom, sata ports) and services turned off and all audio tweaks enabled (write caching, background services, etc)

*I use full performance power mode, core parking disabled, running throttlestop at fixed multiplier, with powermizer disabled and gpu clock fixed

*I use standard vga drivers

*acpi.sys threads are suspended

*ACPI compliant battery method is disabled

*I run the system off of an AVR UPS

The device works on my dell e1705 when using either of the TI based expresscards (Ricoh chipset).

DPC latency hovers around 100us (after significant tweaking) with recurrent spikes into ~300us every 30 seconds or so. If I use prime95, latency drops into the low 80us area with spikes into the ~150s (speedstep/c1e/e1st issue?). TImonitor shows a momentary drop in clock speed every 10 or 15 seconds, even when at full load at full performance...but I am not sure this is related.

My current theory is that the P55 chipset is the culprit. The expresscard slot connects to an intel PCI controller (root port 8), as does the jmicron 1394a (root port 5), giving them both a shared point of failure. There is an eerie similarity here to the "IPod won't sync" usb issue, actually. I'm fairly certain it's a chipset issue, or a BIOS power management issue.

Does anyone have a firewire audio interface they can test with this model?

Thanks!

 

You most definitely have a DPC latency issue as you said. You can investigate it with the Microsoft Windows Performance Toolkit - and people on the Microsoft Technet forums are actually helpful.

Also i don't think running standard VGA drivers is such a great idea. They are slooooooooooooooooooooooowwwwwwwwwww and eat massive amounts of CPU even at the most basic things such as moving a window.

 

I've run xperf quite a bit in all of the above environments...looking back through the logs, it seems that I may misinterpreted the data. The common top abusers are acpi.sys and nvlddmkm.sys (.245972 avg actual duration / 1.281 max actual duration) when I don't have my interface enabled. When I do have it enabled, ohci1394.sys shows 2,448.782ms for actual and 0.451 for max actual. That seems like a smoking gun. The graph shows big plateaus of dpc use that semi correlate to the disconnects...so it's not a spike, but a low, slow hold instead.

But now...the 1394 adapter driver is the culprit, with the function OhciISOchDPC taking the majority of the bandwidth. Investigating further...

 

Well that narrows it to the firewire card or port itself then. You should give the card makers an email, pro audio makers usually care about their products.

 

I've contacted the manufacturer of the card and they feel it's something strange going on in kernel land (which I've shown with the traces), as well.

I've used two different TI based express cards from two different manufacturers, as well as the onboard port and received similar results from all of them. I've also used the legacy 1394 stack and the win7 monolithic stack with similar results. The audio device is confirmed working on a second machine using the express cards.

To me, the only commonality left is the PCIe chipset that ultimately controls both discrete paths...or the BIOS. I could be totally wrong, of course...which is why I was hoping to get data from other firewire / dv7t quad users out there. If others are seeing the same issue I can at least rule out a single faulty unit or confirm an underlying bug.

 

Does W7 x64 Home premium have xperf?

 

You'll have to install the win7 SDK package to get the windows performance tools. http://msdn.microsoft.com/en-us/performance/cc825801.aspx

When installing the SDK, you can deselect all other packages.

 

It appears that I was barking up the wrong tree. I've since found that my audio interface itself was the source of the problem. The manufacturer sent me a replacement, and now the DV7t quad works flawlessly with it over a SIIG fw expresscard. No dropouts at all. So there you have it.

I still would love to be able to disable hyperthreading and c states to see if I could get lower DPC levels, though.

 

It's great that you got it working. Never rule out a problem with the device itself - for example i have a card reader that says USB 2.0, but every time you connect it it says "This device can perform faster" as if it were plugged in a 1.1 port (and it runs at 1.1 speeds). There is nothing wrong with my USB ports and it does this on every computer i have plugged it in.

Don't, and don't. If your DAW doesn't support hyperthreading and dual core you should upgrade. Secondly this is a laptop and there's a very good chance that it'll melt if you do that. I know someone who melted an Acer Ferrari a few years back, by leaving it to render in 3DS Max for 6 hours.

The one really good way to lower DPC levels is to use Process Lasso. It keeps a restraint on "rude" applications and doesn't allow them to choke the system. It can control system processes too, so it lowers overall latency. Plus, the shareware version can be used without time constraints, and it's a "set it and forget it" type of program. In fact i only remembered that i have that running while i was writing this post.