Latency and Audio Dropouts
Serial first...
The problems you're experiencing are typically some "buffer underruns" problems. I will try to explain this to you in old good English (Note of the translator : well, hem, I'll try too ;o). First of all, you must understand how it works... Your computer is not able to read several audio tracks at the same time. The tape heads of your hard drives read only one file at a time... So, in order to be able to read several Audio tracks at the same time, a trick had to be found and it is named buffering.
So, how does it work ? Well, just before the playback is getting started, the CPU asks the hard drive to read small bits of each audio file and to paste them in a buffer, one after the other. Each bit is just read simultaneously from the buffer into the soundcard and off you go, buddy, by the time you read all of this, the hard drive has enough time to fill the buffer again with another small bit of each track... ;-)
That's theory, but it works at only one condition : the buffer must be filled faster than it empties itself, otherwise there would be a time when it would have nothing to read ! And then, you will hear... a short lapse ;-D (that your ear perceives as audio dropouts, because of the speed of the phenomenon and the high DC Offset, which can appear at the precise place where the file starts playing again, but this is another story...)
At this level of the explanation, it is convenient to have a look at the, hem... weaknesses ;-)
-
First point, the hard drive... If it is not able to withstand the important data stream that you will require when reading all of these informations "at the same time", there will be a problem, so you must have a fast and steady drive, UDMA or much better : UWSCSI (1, 2 or 3) for example.
-
Second point, your CPU... It must be powerful enough and have enough spare time to be able to manage the buffering in the best possible way, and this is a parameter which correlates with latency, I will talk about it later...
- Third point, your PCI bus... The Delta 1010 is plugged inside it, but maybe it shares itself in order to leave some room for many other and various things (I will talk about it later too), so that the data streams destinated to the soundcard are "chopped" by these other protocols...
It's getting more difficult here when setting your soundcard... Indeed, the big problem of buffering is... ? Latency ! Yes ! Latency is the direct consequence of buffering ! Indeed, in order to read a file, this one must be read from the hard drive first and written into the buffer ; it takes the same time for the buffer to fill itself. This time, generally expressed in milliseconds, is named latency too... Well, you should tell me, if the latency decreases, just make some smaller buffers so that they would be faster to fill and write, the latency would thus decrease... Well, yeah, it works like this... Only two small problems : you must have a much more stable data stream (and yet the PCI bus sometimes jams, I think) and it forces the CPU to work a lot and to be more available (it must fill and empty these buffers much more often and without waiting, otherwise the buffer will be emptied).
So,
in your case, no real choice, you must do some tweaks. First, notice that
the last WDM drivers for the Delta work pretty well on my system, even
if they have some rather fucking drawbacks, for example the maximum latency
is 28 ms, which is not that interesting, especially if you don't have enough
headroom with CPU power. So, first, open the "Hardware Settings"
menu of the the Delta's Control Panel. Here, verify that the latency
is set to 28 ms, that the Master Clock is on "Internal" and
that the
I want my friends Seb metrot, Gilles Raffelsbauer and Bernard Chavonnet to be kind enough to point out the possible mistakes that should have been written in this exposition, which is not written by a programmer, but a musician / sound-engineer, and therefore it is based only on what I understood of those phenomena :-)
What a talented Serial-P !!! I've got only one thing to add : the lower the latency, the more messages will be sent from the soundcard to the CPU to tell it that it must fill a new buffer. The only way for the soundcard to warn the buffer is to send an IRQ -Interrupt ReQuest. The CPU should then stop its work in progress to answer the soundcard, which probably means swapping tasks (it's not necessarily working on Cubase but on another opened program), and even worse, a changing of protection level. To write it in simple words, there are many function levels to distinguish the tasks of the OS / Drivers and the tasks opened by the user. An IRQ can't be treated by the OS or a Driver. So, if the CPU is working on a User task at this time, it would be forced to change the context to pass in OS protected mode, treat the IRQ, then pass again in User mode. This takes a very long time. All of this is therefore added to latency and that explains a little bit why decreasing latency means a higher request on the CPU.
Little information eventually interesting for those who don't use a PC : it works like this on every system, that is to say that, even on a MAC, there's an equivalent to IRQs, the only difference being that they are hidden to the user. That's very good for 90 % of the population but the problems of shared IRQs exist on MAC too, and as you don't have the possibility to know which PCI connector shares its IRQ with another one, you must test all possible settings.