Search this Site

Latency and Audio Dropouts

You're here : Hardware >Sound Cards

This is the magic of Cubase Mailing-Lists ; Hamid asked only one question about his soundcard's latency and audio dropouts, and he received two detailed answers, one from Serial-P and another one from Sebastien Metrot ! We're talking about the delta 1010, but this exposition remains valid for any other soundcard...

Serial first...

What does what ?

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...

Latency and stability are in a boat...

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).

Adjustments and tweaks fall in water !

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

Multitrack Driver Devices is on "Single" (if you have only one 1010)... Then, go back to Cubase, play a song, open the Performance bar and have a look if something gets into red when it crackles... If the vu-meter of the hard drive does, you should check it and eventually change the disk buffer size in the parameters of the Audio System... My own value is 48 kb, but it's up to everyone to choose (also verify that "M-Audio Delta ASIO" appears in the field "ASIO Peripheric")... If the vu-meter of the CPU gets above 70 %, try to switch off one of the big reverbs that you have put as an insert on the background percussions ;-D If it still crackles from everywhere, I suggest you put your soundcard in another PCI slot, and if they are all in use, to change the place of the different soundcards until it works well... If it's still fucked up, try to cleanly uninstall the drivers (with a "by-hand" cleaning of the Widows registry) and install the last drivers again from M-AUDIO's site. I use version 5.10 under Windows XP... As a last resort, ask your retailer to verify your soundcard. Soundcards aren't fully reliable according to my own experience (mine works well, but it is the third one I've got in 6 months, the first ones have been returned to the manufacturer)...

Errare humanum est

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 :-)

This was done immediately by Sébastien !

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.

Serial P et Sébastien Métrot, the couple that the whole universe envy us... not ;op ;op, on the 14-04-2002

Page viewed 17820 times