Problem with WDM drivers for Delta

  • Thread starter Thread starter bdemenil
  • Start date Start date
Slackmaster2K said:

m-Audio dragging so much ass on this issue has me believing that it is their problem, although I wonder why the fix is taking so long?

Are you still in touch with them?

Slackmaster 2000
Click to expand...

MAudio finaly admited to me that it looks as if there is a problem on <u>my</u> system - believe me, it was hard to convince them that what we're experiencing isn't perfectly normal. Then they told me if it was a real problem (not confined to me), more people would have reported it. Finaly, they left me saying that before they troubleshoot with me further I will have to disable ACPI - I haven't had time to do this yet.
 
Someone else on the Cakewalk thread has reported the problem :

cominginsecond said:
I ran the test in my Delta 44, and I seem to have the problem. I measure the offset at 8ms. :( Kind of upsetting, but, since I didn't notice it before, I'm not going to let it keep me from recording. I may scoot all my tracks back by 8 ms, though. :) Hopefully MAudio gets on the case and fixes the problem.
Click to expand...
 
Damn this ACPI issue. It's all about IRQ's with these m-Audio guys isn't it!??? I couldn't have made it any clearer that I do not use ACPI on my system, and that the Delta 1010 is on its own IRQ.

I could see an IRQ issue causing small stalls & skips, but this problem is too consistant. In fact it's so consistant that I can't believe it's not a software flaw.

Slackmaster 2000
 
Slackmaster... you commented about not enough people testing for the lag problem.

What test needs to be done? (is it mentioned in this thread?) I guess you are asking for visual results to be generated so they can be sent to m-Audio...

Cal
 
Slackmaster2K said:
Damn this ACPI issue. It's all about IRQ's with these m-Audio guys isn't it!???
Click to expand...

It's hyper-lame is what it is. They make a hardware product for PC's, and the fact is that the vast majority of modern PC's are running ACPI enabled. This is analogous to saying something like 'you shouldn't use USB devices when using our pci-card hardware', just a clear symptom of an inadequate testing process.
 
Here is a further elaboration of the results of cominginsecond's tests. His results correspond very closely to those of Slack and myself.


cominginsecond said:
Sure.

Hardware:

Athlon 1600 XP processor
256 MB DDR ram
Spacewalker KT 266a Motherboard
Two Western Digital Hard Drives, one 20 GB and one 60 GB
Delta 44
Plexwriter 12/10/32A CD writer

Software:

Sonar 2.0

OS:

Windows XP.

I was using 384 samples as the buffer.

I reduced it to 64 samples, and the offset was reduced significantly. I would say it's down to 1/5th of what it was.

Has anyone done this test running MME drivers? I'm wondering if the problem is limited to the WDM.
Click to expand...
 
Holy SHIT!

I was feeling left out of this game because Sonic Foundry Software (which did not support ASIO drivers) forced me to use WDM drivers with my Delta but at 24 bits the recording were USELESS garbled noise. SO I had to use the ASIO drivers and Logic Delta, then import the waves to mix them down in Vegas.

BUT, here comes M-Audio to the rescue with their Beta release of a driver that is supposed to work with ACID 4.0 ASIO drivers. Turns out it also "fixed" the problem with the WDM drivers at 24 bits so I decided to run the Slack test for myself.

I got 7.5 ms of lag at 128 samples and 20 ms of lag at 384.

BUT- and this is the real PISSER.

The recorded .wav file on the second track- the one with the lag was INVERTED!!!! So when I went to slide one to line them up, they cancelled each other OUT!!! Not completely, but enough to make that fix useless without sending one .wav through a phase inverter first.

And for the record, out of respect to the first two pages of this thread- even the 20 ms would have gone unnoticed had it not been for our self-proclaimed resident "retard" that went through all this trouble to show us the truth.

I loved that write-up, Slack. I wish all academic papers were written with that degree of clarity.

I guess it's ASIO for me!

Oh- and system info:

Asus P4B266 w/P4 @ 2.0GHz
1 GB DDR RAM
Two 7200 RPM Seagate drives, 40GB system, 80GB data
LG burner
Delta 1010 (beta driver: 5.10.00.0114x2)
GeForce MX-400
NIC and IEEE1394 card
Win XP Home w/ SP1 applied

SF Acid Pro 4.0
SF Vegas Video 3.0
SF Sound Forge 6.0
Logic Delta
 
here is my tests:

1st @ 128 samples = 2ms:

testWDM.gif


2nd @ 2048 samples = 22ms:

testWDM2.gif


P.S... almost forgot... delta66 @ 24bit 96kHz, WinXP Pro, Samplitude Producer 2496 v6.04
 
Last edited:
I noticed everyone was doing 16bit/44.1kHz tests... ok I don't record at this resolution (I do 24/96 usually), but ran a test @ 16bit 44.1...

well the delay seems to be worsened dramatically at this lower resolution...

@128 samples instead of 2ms delay, I got about 4 to 4.5ms delay...

@2048 sample instead of 22ms delay, I got about 65ms delay...

one interesting thing to note, is that these numbers (especially the 96khz numbers) correspond pretty close to the numbers given to you in the Delta control pannel when you choose the DMA buffer size... it also says "latency of INPUT and OUTPUT.." just what exactly that means I do not know...

also, the application I am using does not support WDM KS (kernel streaming), which is really what is needed (or so they say) to get low latency with WDM similar or lower than ASIO... only prog to support it that I know of is Sonar, but we've seen this prob in Sonar as well, so I think the lack of WDM KS can be ruled out.

I dunno, but if there is an output latency with the WDM, then the delay on coming back in makes sense... has anyone with a different card ran similar tests on WDM drivers for their card?? Again, I do not know what M-Audio means when they say "input and output latency of"...
 
>I noticed everyone was doing 16bit/44.1kHz tests

No- if you read Slack's well-written description of the test he's using 24 bit @ 44.1KHz. So did I.
 
drstawl said:
>I noticed everyone was doing 16bit/44.1kHz tests

No- if you read Slack's well-written description of the test he's using 24 bit @ 44.1KHz. So did I.
Click to expand...

16bit or 24bit... you both are doing 44.1kHz... the sampling rate seems to make a difference here... and I was doing 96kHz... as you can see from my results, I got much lower delay with 96kHz... but with 44.1 got about the same as you and Slack... I don't think the bitrate makes any difference here...
 
Yes, the higher the sample rate you use, the less this problem impacts you. However, it is still a problem.

Also, 96khz recorders are few and far between compared to those doing 44 or 48. I'm not picking a fight or anything, I just don't want to take any of the fuel off of our sad little fire :)

Slackmaster 2000
 
I just quickly ran the test on my Delta 1010.

128 samples -- about 10 ms delay.

784 samples --- about 25 ms delay.

The bad news is that I have to go with at least 784 samples or I get nasty pops and clicks.

The good news is that I use Samplitude, which allows you to offset during recording by a specified number of samples. With a little trial and error, I found that when I have a 784 sample buffer specified in the M-Audio control panel, I can get perfect timing if I set the record offset to 854 samples.

So before I read this thread, I was happy, 'cause I couldn't hear the latency anyway even though it was there.
Then I ran the test, and I was sad, 'cause I knew it was there and that bothered me.
Then I set my record offset in my recording program, and I was happy again.


My system:

P4 1.6 GHz
526 Ram
Windows 2k
Delta 1010

Other specs available on request; I'm too lazy to type them in otherwise.
 
Slackmaster2K said:
Yes, the higher the sample rate you use, the less this problem impacts you. However, it is still a problem.

Also, 96khz recorders are few and far between compared to those doing 44 or 48. I'm not picking a fight or anything, I just don't want to take any of the fuel off of our sad little fire :)

Slackmaster 2000
Click to expand...

understood Slack... which is why I went back and re tested at 44.1...
 
Kelby...

I forgot about that function in Samplitude... I set the record offset to the number of samples the DMA buffer was set at, and at 96kHz, this produced a <1 ms delay @2048 samples compared to the previous 22ms... thanks for mentioning that for us Samplitude users.... I suppose messing around I could find exactly where 0ms would be, but setting it to the DMA buffer size and getting between 0 and 1 ms is good enough for me, at least until M-Audio decides to remedy the problem.

P.S... just ran tests at 44.1 using the offset and it was a bit trickier... setting to 2048 did nothing, but to 3000 made it about 1ms latency but it was about 5ms after a few seconds and kept growing... only at 96kHz was the <=1ms delay pretty much constant... sort of weird how quirky 44.1 seems to be acting, while 96kHz provides a stable <=1ms delay using a record offset the size of the DMA buffer in Samplitude...
 
Last edited:
Funny, I believe the offset I've been measuring does not change with sample rate. Last time I checked, I got the exact same offset at a given buffer size at 44.1K as at 96K. It would make perfect sense if it did change, but that's just what I remember seeing. The apps I tested this on - ntrack and sonar - do support wdm kernal streaming - so I don't know if that was the difference. I'm away right now, but when I get back next week I'll double check to make sure I'm not just spreading falsehood.

Anyway, it's a minor point - the important thing is that many people are now reporting the problem. Maybe now maudio will do something about it.
 
I tried disabling ACPI - problem did not go away - not surprising.

Using coolEdit2, with 384sample buffer, I measure a consistent 10ms delay @ 44.1K. At 96K I measure a slightly smaller 8.5ms delay. This is strange since the buffer size is temporally quite different between 384samples at 44.1 and 384samples at 96K. One would expect the delay at 96K to be less than half that at 44.1. All this re-enforces the notion that there is something screwed up with the way the WDM drivers report buffering to the audio software.
 
Well guys I am less than a week away from doing the test myself. The first part of my DAW just arrived!!!!!!:D
 
I just talked to Midiman tech support yet again. The official stance is still that there is nothing wrong with the drivers. They say someone from their engineering department will get in touch with me next week. Until then, I will refrain from venting my full frustration.
 
You must log in or register to reply here.
Back
Top