m-Audio Delta WDM Driver Problems Discussion

Recently it has come to the attention of a few m-Audio Delta users that there is perhaps a serious flaw in the low-latency WDM driver. At this time nobody is sure whether the problem is with the drivers, WDM itself, or the various multi-tracking applications we happen to be using. What we do know is that the problem has been verified with the Delta 66 and Delta 1010 on both Windows 2000 SP3 and Windows XP, using n-Track Studio, Sonar, and Cool Edit Pro.

Links / References

Benjamin de Menil also verified this problem.
Here's one of the initial discussions at the HomeRecording.Com BBS.
So far the problem has only been reported with m-Audio Delta drivers.
I used n-Track Studio for my testing.

The Problem

The problem is that tracks recorded using m-Audio WDM drivers are written "to tape" late, thereby creating an offset between a reference track and the track recorded using the reference track. In other words, if you're recording a guitar track while listening to a drum track, the resulting guitar track will be out of time with the drums - anywhere from ~3 to > 50ms late.

Now this isn't always an audible problem. Most of the time a few milliseconds of track offset won't be noticable because most musicans drift in and out of time slightly while playing anyways. However, I stumbled upon this problem while playing a guitar part that had to be very precise. No matter how great it sounded while I was actually recording, when I'd playback the tracks the guitar was always late. I blamed myself for the longest time, but eventually I tried the following experiment and found that my bad sense of timing was not to blame in this particular case!

This is NOT the same thing as latency!

Latency is an overused term that in the computer multitrack world, and should basically just mean "the amount of time it takes for you to hear the result of an action performed in realtime." That is, latency is only an issue when mixing or when doing live processing of an input stream.

Latency should not come into play during normal *recording* with the Delta (and most soundcards) because it supports "Zero Latency Monitoring", in which incoming audio is routed directly to an output prior to being processed.

Quick Results

For those who don't want to read all the long-winded crap that follows, I have demonstrated that track offset when recording with Delta WDM drivers occurs at a severity dictated by the Delta DMA Buffer Settings, and only the Delta buffer settings. The buffer settings used in the recording application itself do not appear to have any impact.

Using Delta ASIO drivers I could not create any abnormal track offset. Regardless of the Delta buffer settings, track offset was always consistant at about 1.5ms. I believe this to be how the card should perform regardless of the driver model chosen.

If you absolutely must recording using Delta WDM, set your Delta buffer settings to a very low value (e.g. 64, 128), and then adjust the buffers in your recording application to taste. This does not eliminate the problem, but it does reduce it. A better solution would be to record using ASIO, if possible, and then switch back to WDM for mixing (if you prefer WDM).

Test Procedure

To verify that this problem does exist, I performed the following experiment:

1) I created a simple click track using a hi-hat sample in Fruity Loops. I wrote the click track to a wave file and imported it into n-Track.

2) Using a patch cable, I routed one of my Delta 1010's outputs (#2) to one of its inputs (#3). See picture below:

3) In n-Track, I armed only input channel #3, and n-Track outputs on Delta Channels #1 and #2 by default. Therefore, when I hit Play or Record in n-Track, the output from channel #2 will be routed back into input channel #3.

4) I set n-Track to use "WDM - M Audio Delta 1010 Multichannel" for both its input and output device.

5) I set my Delta Control Panel DMA Buffer Size to 128 samples, and set my n-Track buffer settings to high.

6) I hit record.

7) I saved the newly recorded file with an appropriate filename, then removed it from the project.

8) I opened both the original click track file and the newly recorded file into the same window in Wavelab 4.0, and zoomed in until I could accurately measure the offset between the second click in the track (arbitrarily).

9) I repeated steps 4-8 several times using the following parameters respectively: [WDM, Delta DMA 128, n-Track Low] [WDM, Delta DMA 2048, n-Track High] [WDM, Delta DMA 2048, n-Track Low] [ASIO, Delta DMA 128, n-Track High] [ASIO, Delta DMA 2048, n-Track High]

NOTE: All recording was done at 24bit, 44.1Khz.

Test System

Celeron 850Mhz
Abit BE6 BX440 Motherboard
256MB Crucial PC133
30GB 7200RPM Maxtor HD on onboard Intel UDMA/33 controller
15GB 7200RPM Maxtor HD on onboard Intel UDMA/33 controller
Sony 8x4x32 CDRW on onboard Intel UDMA/33 controller
Geforce4 Ti4400 64MB Video (main)
S3 Trio64 2MB Video (secondary)
3Com Etherlink XL 10/100 NIC
Creative Labs Soundblaster Live!
m-Audio Delta 1010
Microsoft USB Mouse, Microsoft USB Keyboard

Windows 2000 SP3, Standard PC HAL
n-Track Studio Version 3.1
m-Audio Delta 1010 Driver
Wavelab 4.0

Recently I was told that the guys at m-Audio thought I had an IRQ problem. While I've never seen an IRQ problem that looked anything like this, I figured I'd better post pics of my actual system configuration.

IRQ Setup

IRQ Sharing

Current HAL

Windows Version

Current Delta Driver Version

NOTE: The following results were also verified on Windows 2000 SP2, n-Track 3.0.5, and m-Audio Delta 1010 Driver

WDM Results

NOTE: All recording was done at 24bit, 44.1Khz.

Here we go, first we'll start with a typical WDM setup - low Delta buffer settings and High n-Track buffer settings (high buffers mean: Playback 21504 samples, Record 204800 samples)

Here we see that the offset is approximately 4.5ms.

Next, we'll crank the Delta buffer settings up to 2048 samples and see what happens:

Oh boy, the offset is now suddenly just about 50ms! More than unacceptable!

To see if n-Track buffer settings have any impact, lets try both of the above using low buffers in n-Track (low buffers means: Playback 65536 samples, Record 6144 samples)

As you can see, n-Track buffer settings don't appear to have any impact on track offset, producing identical results when buffering considerably fewer samples.

ASIO Results

Ok, now let's check things out with ASIO. Since I pretty much knew that this was just a WDM issue (not very scientific I guess), I just decided to try two tests.

First, we'll set our Delta buffers to 128, and since we're dealing with ASIO, n-Track will use these buffers:

As you can see, the offset is approximately 1.5ms.

Next, let's crank those Delta buffers up to 2048 samples and see if we introduce more track offset:

Nope! As you can see the offset remained consistant at 1.5ms!

Results Summary

WDM Results
Delta Buffers n-Track Buffers Approximate Track Offset
128 samples High 4.5ms
128 samples Low 4.5ms
2048 samples High 50ms
2048 samples Low 50ms
ASIO Results
Delta Buffers n-Track Buffers Approximate Track Offset
128 samples N/A 1.5ms
2048 samples N/A 1.5ms


First I'll conclude that I'm a retard for spending almost two hours putting this thing together!

Second, it certainly looks to me like this is a problem with either m-Audio's Delta WDM driver, WDM itself, or n-Track's WDM support. Obviously the amount of track offset using WDM is directly related to the number of samples selected in the Delta Control Panel DMA Buffer Settings box. This problem does not occur when using Delta ASIO drivers.

WDM Best Case

The very best track offset I could get using WDM was approximately 3ms using Delta buffer settings of 64 samples. However, a setting this low did have a negative impact on performance when I tried working in my 24 track test project. In real life I've found it necessary to use at least 256 samples, which produces offset > 10ms, which is unacceptable.


All content Copyright 2002, Boden Larson (Slackmaster 2000)
Please contact sm2k@slackmaster2000.com with any questions or concerns.