It's all in the time----ing...
From the original Analog Industries archive. Some links and images from that era no longer resolve.
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?
24 comments
I have heard that using a second hard drive and streaming off of that for all your larger files can make a big difference.
"The audio is streaming off a half-TB RAID 0 array" I think I said. You've heard that because it's correct. To save everyone a lot of typing, if there's an obvious solution (like the above) or a helpful tip, you can rest assured that I've done it. My system is a top-of-the-line computer, tuned by someone that makes a living making music and software.
This is an esoteric issue, and there's an esoteric answer; I just haven't run across it yet.
-CR
How large block sizes you use on the raid? Maybe the cpu is chuffing on streaming too many small clusters? How does the raid connect to your system?
i think i read that the RIAA and Microsoft decided that you couldn't use Vista to play 16th notes.
The RAID is the SATA RAID controller (a Silicon Image 3512) on the motherboard. I'll fool with the block size; that's not a terrible idea.
-CR
Strange... I have had extensive problems with MIDI timing but on the other side of the coin, when I am laying down the first few MIDI tracks. This was on SX1, and come to think of it, I haven't noticed it since upgrading to version 3.whateva. I assume you have checked all of your sync settings, I seem to remember some timecode options there... perhaps like sending timecode info out to the MOTU via software. You have probably done this already if it's even possible, but I do not know. I am thinking while I am typing, instead of beforehand... HD, audio... hmm. If your compy is badass in the memory dept., perhaps you could change your disk cache settings to shift the activity from the disks to the memory. Doesn't the RAID array duplicate all of your data and pull it alternatively from two drives in order to double read/write times? If so, you would really need 3-4 drives to truly get audio poppin' on it's own drive. You know this too, thus the "audio is streaming off" part of the post. 2 strikes, one ball.
Only other thing I can think of is the USB nature of the MOTU. I notice significant performance gains by switching off a single usb device (Radeon controller) in projects with a lot of audio. This sucks when I am trying to add MIDI-based tracks to a project of my own. The last suggestion would be to decrease the priority of audio from "very high" to "high" ot the step below that. OK, three strikes... I'm outta here.
Peace Fish,
Is the Motu MIDI on USB? Perhaps another USB device is stealing bandwidth/CPU cycles via some background service? Or the USB IRQ is shared with the RAID?
It is USB. (I find that USB MIDI interfaces are almost always annoying in some form, fwiw.) However, it's one of those fancy new-fangled drivers; AFAICT there is no IRQ assigned.
The RAID has one, of course.
To answer thesimulacre's last point, I've been fooling with the priority and buffer size and how they relate. In a high track-count song, if I put audio priority to "low" then I can run at a lower buffer size (call it 512) and get reasonably accurate timing. I'm currently trying out the DirectMedia emulated ports, since I've read a couple places that MOTU interfaces are happier with them.
Christ, this is annoying.
-CR
It might be the RAID setup actually. "Onboard" RAID controllers are actually implemented largely in the software drivers, and often make very poor use of interrupts - which spells increased access latency, especially as the number of simultaneous accesses increase.
Also, these limitations will be "hard", as in running software won't be able to recognize it because it doesn't operate on a driver/kernel level.
Do you get the same effect when streaming off a single, non-striped, hard drive?
As a sidenote; performance-wise, using modern drives, it's unlikely you'd need striping unless you need several hundred MB/s throughput.
You wouldn't by any chance still be running some of your VSTs in Novation Automap-wrapped-mode would you? I had some major MIDI timing issues with my Automapped Battery VST last week and had to disable it. Obviously this shouldn't affect MIDI going to your external gear, but it couldn't hurt to disable Automap if you're still using that Remote SL.
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.
-CR
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
Almost as glad as I am that I ditched OS8.5, I bet.
-CR
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....
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.
the problem starts with the words "raid controller on the motherboard." and ends with "30 to 50 stereo tracks".
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!
What's stupid about a hardware interface for plugins?
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.
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: http://www.mark-knutson.com/t3/dawguse.html 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.
"in my mind and in my car
we can't [system] restore we've gone too far
Vista came and broke your card
Put your blame on PCI.
Video killed the MIDI I/O
Video killed the MIDI I/O
Video killed the MIDI I/O
Video killed the MIDI I/O"
--Adam
I'm actually having nagging Mac software issues at the moment, so this isn't a sneer at PC headaches, but part of what you do get with a Mac is an OS that is obliged to support Apple-supplied video cards, etc., over quite a long period of time.
Well the Vista driver issues are largely Nvidia's problems. Other vendors are at least stable & performing somewaht decently. It's a well known issue in the 'pc' world. Kind of strange too because Nvidia typically has far more robust driver sets than ATI & co, especially where non-gaming features are concerned.
Hopefully someone will read this late addition.
One possible Kludge around CR's problem would be to remove the video card entirely from your music box and use remote desktop (or Dameware, etc.) to control the unit remotely. FYI the latest incarnation of remote desktop supports dual monitors. If you're using your computer to edit video this obviously won't work.
I've always thought that a good way to go would be to have one stripped down computer running a pure sequencer app for MIDI I/O sync'd to a computer doing all of the audio processing.
If anyone out there is thinking of writing such an app; please include a test suite that will measure average MIDI processing delay times for each outboard unit so that each unit's response can be 'normalized'. Also add to this a MIDI interface that doesn't add time delay to socket "8" relative to socket "1"
BTW, has anyone fooled with elektron's TurboMIDI unit? It's supposed to produce more accurate timing by increasing MIDI bandwith 8-10 times. I assume it only works w/ elektron's units.
Comments are closed on this post.