Alesis I/O, Konnekt, Firestudio, Dice-II chipset interfaces

[vcovco]

I am going insane with this...seems that ANY audio interface with this chipset has problems where the CPU utilization jumps from 1 up to 40% even with the system at an idle.

Can the owners of any of these audio interfaces confirm?

Alesis I/O, TC Konnekt, Presonus Firestudio

Might be others I am missing. To test in Windows, do a CTRL-ALT-DEL and choose task manager, then the performance tab and basically just watch to see if your CPU utilization jumps up and down in a cyclical fashion even with no programs open. (I forget how to view cpu graphs on a Mac)

I am told it should have no effect on audio, but I see it to be a problem where % Deferred procedure call time is way higher than it should be which is causing these cpu spikes. Its happening to me on a firestudio project, and it happens on the regular firestudio. I've written to TC Technologies who designed the chip to see what they have to say, but just trying to see how many others are affected.

thnx!

[santibanks]

Sorry to say I can confirm it for the Firestudio on Macintosh (macbook, iMac g5 and the latest imac)

[vcovco]

Rainy...has this led to dropouts or other issues for you?

[Robobaby]

I was going to buy a TC Studio Konnekt 48 in the next few weeks but what with driver concerns I was holding out until I could get some feedback. I have a question if thats ok with you folks?

I frequently work on projects at high CPU load because I use predominately software instruments and effects. Its quite common for me to be bordering on 90%+ CPU load most of the time and adding another software instrument can make the difference between a project playing back smoothly and it turning into a stutering mess.

Will these CPU spikes (related as you think they are to DICE-II) cause problems for people working at say greater than 60% CPU load constantly?

[vcovco]

Hi Robobaby.

That is what I'm trying to find out. Frankly, I don't buy the notion of 'ghost' spiking. I've tested in Windows perfmon and %DPC time is causing these spikes, or to rephrase, the CPU is spending an inordinate amount of time servicing the interface. I often load up on VSTi's and push the CPU to its limits, so that is why I am so concerned.

I guess I'll have to start testing further, and if anyone else can share their experiences, that would be great. It kills me because these interfaces are pretty decent otherwise. Some people's answer is to not worry about it, but unfortunately, I obsess about stuff like this and want my gear behaving...

[vcovco]

Well, I thought I would chime in here with some new info. I think it is safe to say that these CPU spikes occur in all interfaces that use the DICE-II chipset. I got so fed up with it that I contacted tctechnologies who manufacture the DICE-II chip and I got a response from the CEO himself! He was very courteous and explained the phenomenon in detail, and just as some have mentioned, the spikes are not necessarily indicative of cpu load, but of the way Windows samples CPU stats in perfmon versus %DPC time.

I am still struggling with why it doesn't happen on other chipsets, but I think at the end of the day, it comes down to how audio companies handle latency and audio streams in their design.

It is not seen as a problem, which is a shame in my opinion, so therefore, it will not be fixed.

Bottom line I have found in my own testing spikes or not is that these DICE-II interfaces chomp up more CPU versus the echo audiofire or even presonus' own firebox I tested. So my final verdict is you can't have it all at the $500 range

Echo audiofire = slightly higher ASIO latency, lower cpu utilization
DICE-II interfaces = slightly lower ASIO latency, higher cpu utilization

FWIW...I think the Echo audiofire 4 sounded a tad better than Alesis I/O 14 or Firestudio Project...was able to drive it more before clipping than either of the latter...

[Testing123]

How often do you see the spikes? I don't remember seeing them when running my Alesis Multimix 8 Firewire, which I believe also uses the Dice-II chip, but I wasn't explicitly looking for that either so perhaps I missed it.

-Keith

[santibanks]

I have them all the time. When I still ran the iMac G5, the firestudio was useless to me. I couldnt do anything. Bought a mackie onyx sattelite which worked much better on that system.

Got the new iMac (2,4) and the onyx works even better. The Firestudio runs a bit better too but its not perfect at all. THere are indeed spikes which can clearly be seen with tools like VUmeters or just the internal CPU metering in Digital Performer.

[vcovco]

yes...pretty much as long as the unit is powered on.

[digital lofi]

Interesting find.

I've been pretty happy with my i|o26 and it has a great feature set.

But you're absolutely right about it causing CPU spikes.

On my just-installed AMD 64 dual-core 6000+ simply running the Ctrl-Alt-Delete CPU monitor doesn't reveal much - it simply shows a steady 2% or 3%. However if I use the AMD processor power monitor it shows core 1 jumping around in the 3% to 30% range. When I use the task-bar Remove Hardware Devices to turn off the i|o it settles to down to no discernible usage at all.

I am going to load up one of my heavier projects and check that out.

I wonder if a new driver would address this?

[vcovco]

Presonus has no plans to fix as far as I know. I would venture to guess TC Technologies is doing the heavy lifting driver work for all of these interfaces, and seeing as how TC does not see this as an issue, I would not hold your breath.

Again, don't take the spikes as true CPU load as part of the spike is just Deferred Procedure Call related (IRQ's n buffers n blah blah)...firewire devices in general suck up more CPU than PCI...I just believe that somewhere in those spikes is an indication of a higher overall avg CPU load....

I think I am ditching firewire all together...I want lowest ASIO latency/lowest CPU with pristine sound, and so far out of echo audiofire 4, presonus firebox, alesis i/o 14, and presonus firestudio project...I have not had the magic combination of all 3 yet.


This sounds crazy, but I just ordered up an EMU1616m PCI as a last ditch attempt at a cheap-ass golden sound device with XLRs and decent pre's, which I firmly believe you can achieve for under $500.

If all of this fails, I am opening up my trusty Maudio delta 44 and soldering in new op-amps my damn self!!! (Believe me...I know the specs on this suck, but it has not given me an ounce of problems since I got it...which was whenever NI released their original Pro-5 VSTi...5..6 years ago?)

[digital lofi]

Firstly, let's just say, dual-core really skews my expectations of what I should be looking for. It's just a whole different ball-game.

These projects that I thought were mighty are barely causing any activity in the Sonar CPU monitor.

The AMD power monitor, well, it's hard to tell if the inherent CPU overhead of the driver is actually causing greater spikes in the CPU consumption. That is, without completely putting in a new driver. There's so much activity going on who really know.

Thanks for the additional info. Any chance you could snip in the explanation from the TC bigwig as to what exactly this means and why they think it doesn't need to be addressed.

Of course, I don't really understand any of this underlying stuff, and if the Alesis continues to work for me without hassle I shall continue to use it.

However, lately, as I read more and more here and other places, I'm more convinced that my initial computer audio interface setup was actually a pretty advanced bit of kit, albeit more by luck than design. I had an Event EZBus hooked up via S/PDIF to an MAudio 24/96 PCI card, synced to the EZBus. I can now see that the AD/DA, pre-amps and clock on the EZBus were actually pretty top-notch. The USB audio was all but useless, and the control surface cumbersome and kludgy. But its top notch digital electronics combined with the solid Windows Delta drivers made it a pretty unbeatable system.

Lately, I'm thinking of ditching firewire and hooking that back up. Of course, I'd loose the turntable pre-amp which has proved to be very useful.

[vcovco]

Sure...let me just ask him if he minds if I post it. I haven't heard back from him in response to additional questions I had for him, either...probably doesnt want to bothered with a pest such as myself

[vcovco]

Gang...as I promised, here is part of the info that I got from TCTechnologies that explains this spiking phenomenon, and topped with my last correspondence, I must say that I am a believer now...The spikes may very well not be accurate.

I really have to throw praise on ALL the companies out there creating audio goodness for us musicians, especially the ones that have to deal with the wildcard variable of somebody's bleeping computer.

So my hat is off to Rick (and Wesley) at Presonus and the folks at Echo Audio and TC Technologies for putting up with my pesky questions and for taking the time to address my concerns.

Like I said before, I've personally found that the Firestudio Project appears to use slightly more CPU than audiofire, firebox, and now EMU1616m, but I suppose in the end there is always a tradeoff for low latency and high throughput...

(FWIW...I've now tried an EMU 1616M PCI and I do get better latency with the FS Project, which is saying something for firewire vs PCI)

Detailed explanation for hardcore users follows (I really felt this info needed to be shared...hopefully you'll find it as enlightening as I did):

--------

DPC latencies:
The term DPC stands for Delayed Procedure Call and it is the principle used to get work done in the kernel. The kernel holds a list of DPC’s per processor and they are scheduled in a sequential manner, one after another. The priority is first in first out. Drivers under Windows schedule such DPC’s to be called when they need work to be done, this could be a result of a timer or of a buffer issued to the lower layers being sent.
If a driver chooses to spend a lot of time in a DPC call all other applications have to wait. It is essential that DPC’s finish their work as fast as possible, because if they don’t they will defer all other processing.

The size of the DPC latencies does not directly translate to CPU load. The example below illustrates that:
1)A driver holds a DPC which is called every 100us and it uses 10us to complete, this will take up 10% CPU load but show insignificant DPC latency (10us)
2)A driver holds a DPC which is called every 10ms (10000us) and it uses 500us to complete, this will take up 5% CPU but it will show up as 500us DPC latencies.

While the DPC latency itself is not a measure of the load of the CPU it does affect the latency of the system, as no driver would be able to process with a granularity less than the max DPC latency. When developing a driver that can exhibit low audio latency there is a compromise between obtaining low latency and avoiding clicks every time another driver creates a large DPC spike. In the DICE drivers this is balanced by the ‘safe mode’ setting. Higher ‘safe mode’ makes the system less sensitive to DPC latencies (insensitive to anything below the ‘safe mode’ threshold) by relying on more buffering in the kernel and therefore more latency.

CPU Usage:
Ideally this would show the load of the CPU and on average that is exactly what it does. It is based on a statistical sampling method. Unfortunately this is greatly undersampled so the chance of getting ‘beating’ in the measurements when measuring something which uses the CPU at a steady frequency (such as an audio driver) is quite high. Several factors come into play and it is actually possible to make a driver which will take 90% of the CPU time and still show close to 0% utilization on the meter. The problem is that a multiple of the regular small usage of CPU by the audio driver will line up with the CPU meter sampling frequency once in a while and create the cycling I believe you are describing. Furthermore a large DPC spike will postpone those processes so they all line up to happen right after the spike, and that could result in this aliasing problem appearing. When the computer has more than one CPU this becomes even more complicated to predict.

Here is an example of the undersampling; Let’s assume that a driver runs code every 200us and that the code takes 10us to complete, this is on average 5% CPU load. Let’s assume that the CPU meter samples every 1ms (1000us) which is quite likely. After asking who is running for 1000 times we would assume that 50 of those times it asked when this kernel process was running and it will show 5% on the meter. Unfortunately this is undersampled so in the real world the 200us will not line up with the 1ms every time, they will drift.
Let’s say that for a while they are lined up so that every time the CPU meter asks it hits our kernel process, then this would show up as 100% usage even though we know it is 5%. On the other hand, if the CPU meter asks right after our process then it will never see it and it will report 0%.

This link to the Microsoft Knowledgebase explains a similar issue reported but not specifically related to audio drivers: Performance Monitor Reports Inconsistent Data About CPU Usage

[digital lofi]

Hey, thanks for publishing that.

Don't understand half of it but I'm going to take it on faith, and until the driver actively falls down on me, I'll assume it's working as expected.

[miscend]

Hi sorry to bump and old thread like this. But:

Has this issue been fixed for the TC Konnekt 6 and 8? I believe they both use the DiceII chips.

[vcovco]

Not sure...

Been a while...I had since upgraded to a quadcore setup and had gotten over analysis paralysis of the spikes. Things were workable until I decided to take the plunge to Windows 7....instant brick.

I did try switching my firewire to 'legacy mode' in device manager along with Vista drivers to no avail.

Then, I tried numerous 3rd party firewire/1394 drivers which didn't work. I was about to give up, and tried the legacy mode again, and it actually is working now with latest Vista drivers.

No sign of Windows 7 drivers on the horizon...I did some quick searching in the TC Konnekt forums and looks like they are having similar issues....

Unfortunately, it seems like results will vary for everyone depending on motherboard/system setup...

[vcovco]

Well...I stand corrected. Presonus just threw up some Windows 7 Beta drivers...just installed...so far so good and I was able to revert to normal windows 7 firewire drivers.

I do still see the spikes, but oh well...need to focus on making tunes like we all do...

Thanks Presonus for the drivers

[drMelbo]

ok, I am answering my own post above... after heading over to TC support and composing an email very similar to the above, it ran an auto search on their knowledge base and popped up 5 links that it suggested could be relevant, saying if these didn't help then submit the email. Well, a couple looked pretty good:

http://tcsupport.custhelp.com/cgi-bin/tcsupport.cfg/php/enduser/popup_adp.php?p_faqid=2425&p_created=1226578166

http://tcsupport.custhelp.com/cgi-bin/tcsupport.cfg/php/enduser/popup_adp.php?p_faqid=2426&p_created=1226579406

The first one basically tells how to do a full clean uninstall of the TCNear drivers, and then reinstall the latest, but also mentions some DPC safety modes in the TCKonnekt "system" configuration that could help prevent dropouts. The second link talks about juggling devices on your IRQ levels, which also sounds promising but I didn't need to do it.

I performed the first procedure and found the safety modes helpful; also there is a "DPC Spike monitor" utility which suddenly went through the roof during a dropout. A message said the main cause of DPC spikes is network drivers, so I disabled my wireless LAN connection and bingo - everything is looking pretty stable. Wow. I am now back in "normal" mode and things are looking pretty good.

The following link also has some tips for optimizing Windows performance that I found helpful. Needless to say, I didn't submit my email. The 24D has been discontinued, which I guess everyone knows, but they are still supporting it.

http://tcsupport.custhelp.com/cgi-bin/tcsupport.cfg/php/enduser/std_adp.php?p_faqid=1987&p_created=1195738647&p_sid=*nTnCIUj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9NSw1JnBfcHJvZHM9MTg5JnBfY2F0cz0wJ