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
Links / References
Benjamin de Menil also verified
Here's one of the initial discussions
at the HomeRecording.Com BBS.
So far the problem has only been reported with m-Audio
I used n-Track
Studio for my testing.
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.
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).
To verify that this problem does exist, I performed the following
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
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.
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 5.10.00.0026
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
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 5.10.00.0027.
NOTE: All recording was done at 24bit,
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.
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!
||Approximate Track Offset
||Approximate Track Offset
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.