May 17, 2007

It's all in the time----ing...

by Chris Randall

I'm having an odd problem with my system, and I was wondering if perhaps one of my dear readers has had a similar problem, and what the solution might be. Here is the general layout of things:

1. When I have an empty project with no recordings playing back (and thus no disk access) my MIDI timing is rock-solid sampleframe accurate. This is MIDI either being played back from the sequencer or being passed through to an external device. (I'll grant that the latter is hard to test, and I'm more or less just going on feel.)

2. The more tracks I add to the project, the worse the timing gets, and by the time I'm up to my normal track count for an instrumental (which is 30 to 50 stereo tracks) the MIDI timing is so bad as to be essentially useless. Here is an example. What you're hearing is 32nd notes fired every 16th from the DAW to an MKS80, and recording the result. The only way I can get it that good is to open my buffer all the way; I normally run it at 64, but with it set that low, maybe 5 of those notes will trigger, and in the wrong spot, natch. That's at the AES16's highest buffer setting, 1024.

So that's what's happening. The rig is Cubase 4 on Vista Business, on an Athlon64 machine. The audio is streaming off a half-TB RAID 0 array, and the MIDI interface is a MOTU MIDI Express 128. I have tried all the usual methods of getting Cubase to comply; you can rest assured on that account. I've been using PCs for music for over a decade, and Cubase almost that long. I know how to run and tune this rig; this is why this particular issue is giving me some trouble, as it falls outside my experience.

In any event, it is obviously related to the disk streaming. The more audio that is getting played back from the DAW, the worse the timing. Anyone run in to this before? If so, what's the fix?



Page 2 of 4

May.17.2007 @ 5:27 PM
Chris Randall
I did that as soon as I switched to Vista. I discovered that MIDI output from the Remote was causing the Evolver to reset in some unsettling ways, and I unplugged that bitch. I haven't even installed the new Automap shit. Quite frankly, (a) I don't trust anything that wants to wrap VSTs (for obvious reasons) and (b) I don't need a hardware interface for plugins. I find that to be incredibly stupid.



May.17.2007 @ 8:02 PM
totally uncalled for, completely unneccessary, probably a bit chauvinist, but hey i had a few beers:

i'm so glad i ditched MS all those years ago :p


May.17.2007 @ 8:21 PM
Chris Randall
Almost as glad as I am that I ditched OS8.5, I bet.



May.17.2007 @ 8:55 PM
Yeah, it looks like its your RAID config that is "stealing" CPU cycles from lower priority tasks(i.e the MIDI controller). So you end up with symptoms showing up against processes other than the culprit - confusing.

We had all sorts of problems with Silicon Image drivers(tho not on RAID controllers) and RAID in general - we were less than impressed by "in the field" performance of RAID 0, and like you we write and deploy real-time DSP for a living.

The suggestion to try running 20 or 30 tracks of audio off a non-RAID drive and see what that does is a long way short of dumb. It'll be a hassel to do I'm sure but it defines RAID as either the bad-guy or not straight off the bat.

We ended up just using straight SATA drives for "local machines" - by which we mean anything less than a Sun V440. Of course this means doing regular type back-ups and having a larger window of risk, but you're PC develpers so whip up some over-night back up code to copy to DVD based on the file time-stamp. In fact this wouldnt be the worst product you could introduce for the DAW based musician....


May.17.2007 @ 10:29 PM
I ditched Cubase years ago because of the whore-able midi timing. Thought it would have been fixed by now. Try doubling your BPM and recording in half time.

May.17.2007 @ 11:02 PM
the problem starts with the words "raid controller on the motherboard." and ends with "30 to 50 stereo tracks".

May.17.2007 @ 11:32 PM
1. If you peruse the Unofficial Access virus (TI) board, you'll find that many users there had timing problems controlling their units via usb w/ PC's until they started to run off a separate USB controller card. It's cheap and it's worth trying with your MIDI interface.

2. Ditto on the previous suggestion about running disk i/o off of a separate controller card.

3. More esoteric and I'm sure you already thought of this; you can assign different processes different processor affinities under windows task manager. Even single core cpus usually show up as dual processors because they're hyperthreaded. Theoretically you could look at % cpu process utilization during playback, find processes concerned w/ disk i/o and and assign them to one processor. Then run some heavy USB stuff and find processes w/ higher utilitization and assign them to the other processor. I have no idea if this will work! Maybe hyperthreading is the villain. Try a dual core Athon 64.

4. Borrow a Midex 8 from a friend and see if Steinaha's now unsupported LTB protocol really makes a difference. Unfortunately will only really work w/ XP, supposed to work w/ 32bit Vista yet requires kludging galore.

It really pisses me off that in this day & age no one has come out with a midi interface w/ as solid timing as an Atari running cubase!


May.17.2007 @ 11:35 PM
What's stupid about a hardware interface for plugins?

May.18.2007 @ 12:55 AM
I think Linden and itdoesn'tsuck are on the right track. If the RAID and the USB are both on the motherboard, the RAID could be crowding out the USB. A usb controller card may or may not solve the problem but it's worth a try. A RAID controller card is a better idea (RAID on motherboard tends to suck) but obviously is a lot more hassle.

May.18.2007 @ 7:53 AM
Chris did you have disk issues that led you to use the RAID in the first place? There might be other solutions there if so.

For example with proper distribution of your workload over 2-3 drives (one for OS/apps & swapfile, one for 'sample library', one for working projects etc) there usually isn't any need for RAID. Also things like defragmenting a project drive while you have projects in progress can be detrimental to performance if you have longer sections of audio that are recorded simultaniously (and interleaved naturally during recording). This stuff may be totally obvious to you though.

I agree with everyone's sentiments towards onboard RAID solutions as well.

The extra 'onboard' RAID solutions for SATA Raid & PATA Raid (on older motherboards) are awful all around and should be avoided outside of use for 'additional' drives that you don't use when you're in a working mode (backup drives etc). Even intel's SATA implementation uses cpu (where scsi would coprocess for proper RAID). And then of course there's access to the system bus (IRQ hell) and the added complexity that ACPI and EFI bring to the IRQ landscape.

Btw "Class compliant" USB devices have a bit of eeprom (or etc) inside that includes a loader & driver (which I think is what you were referring to), but that doesn't negate the need for an IRQ. The MOTU's irq would be the irq of the USB controller that that USB port is connected to.

Refer to my statement above on ACPI & EFI in regards to this. The easiest way to clear issues up here is to disable onboard devices you don't need (this usually includes onboard RAID chips for now obvious reasons) to clean up your irq 'pool' that ACPI/APIC will shuffly around. And then use a tool like Doubledawg to inspect the PCI latency timers for each peripheral: link []">link [] I think SiSandra and other tools can do this as well. Graphics cards are usually the worst of the lot, but my RME Hammerfall PCI card's driver sets its latency to the maximum (255). That particular device I'm quite happy to have at 255 though. I'd be curious what that RAID chip is set to.

Lastly, a bit of system tweaking info. I've used xeons for audio since applications finally started supporting Win2k & XP, and I've never needed to do the 'background tasks' optimization to get ASIO to work properly. It used to make a somewhat noticeable difference in the P3 era, but on my modern Xeon boards I've tried it both ways several times and not really noticed any difference either way, down to 3ms ASIO buffer. You might try setting it to 'foreground' tasks instead if you did the 'background tasks' optimization and see how things fare with a large project open.


Page 2 of 4



Sorry, commenting is closed for this blog entry.