Problem with WDM drivers for Delta

  • Thread starter Thread starter bdemenil
  • Start date Start date
i lowered my m-audio buffer settings to 256 make it 5 ms after i read the thread ...changed buffer settings within sonar same delay from start point as the other sonar buffer settings

and my OS is XP pro
 
OK, I misread my data somewhat -


With DMA 384 sample buffer size I get only a 3ms delay - still not good

With DMA 2688 sample buffer size, I get about a 35ms delay - very bad

With ASIO - regardless of buffer size, I get maybe 3/10 of a ms delay - very good - the way it should be.

I've posted all these corrections to the URL I mentioned earlier :
http://www.iasorecords.com/public_html/images/album/maudia_dma.html

Teacher - try putting your buffers all the way up to 2688, and see what you get.
 
Last edited:
Ok, we need to clear some things up again:

1) Lag or track offset is NOT the same thing as latency. Latency is the amount of time that it takes from the time you perform an action, to when you actually hear the results of the action. Latency should not have any impact on your actual recording process, as it only comes into play during MIXING or live input processing. What we are talking about in this thread is track offset, where the samples in a track are *physically* recorded at a later time (in the actual file) than they should be. The only way to correct for offset is to move the new track back in your multitracking application.

2) You can't do an objective test by listening in this case. As was pointed out a couple times, the amount of offset we're talking about here is only a few ms. You cannot hear this when performing this test, except at the extreme (e.g. when offset rises to 50+ms). You need to use a wave editor to zoom way in on your original track and the recorded track to measure the true offset.

3) ONLY the buffer settings in the delta control panel produce offset, and ONLY when using WDM in your application.

4) It is possible that this will have no real impact on your recordings as long as you keep the delta control panel buffers extremely low. I've found that they are really inconsiquential when working with WDM, so setting them to <256 samples is usually doable as long as you set the buffers in your application high enough. The PROBLEM with this, however, is when you mix WDM and ASIO applications (or DS, MME, etc), because they all share that same stupid buffer setting, and your ASIO app probably isn't going to perform well at a buffer setting of 256ms.

bdemenil, I am now interested in why you see an offset of 3/10ms using ASIO where I see a steady ~1.5ms offset. That's kind of strange!

Slackmaster 2000
 
i've been keeping up and reading all of this...BUT -

whats the big deal? so we'll all use ASIO and be fine correct? i mean, what is BETTER about using WDM anyway?
 
Well, some apps don't do ASIO. Also, on my system WDM performs way nicer than ASIO in n-Track :( If you're pretty much happy with your current setup and are using ASIO, then you can probably just ignore this for now.

Slackmaster 2000
 
Some applications - like Sonar - do not support ASIO drivers. NTrack also works better with WDM - less skipping - no occasional crackles and skips like with ASIO.


Slack, I found that at the lowest buffer settings, I get some crackle even when I set my buffering high in the audio app. I usually use 24bit 96K audio - I don't know, but maybe it's harder on the buffers. I probably can't get the thing to work well with less than 3ms delay. Considering I'm getting such low delays with ASIO, makes more sense for me to stick with that. Also, it looks like ASIO may perform even better at higher sample rates. I'm going to check the ASIO delay on my other system to see how it compares.


Ben
 
Oh Lordy, I have a delta 1010 and plan on getting Sonar XL, I´ll run the tests in a couple of weeks when I get my DAW up and running, till then, I´ll watch the outcome of this closer.....
 
SM2k,

Are we clear that this is a problem with the LATEST rev of WDM drivers? Because your page doesn't mention that. The latest according to the driver page is 5.10.00.0027, different that the version you list in your config section.

I am recording with Sonar 1.3.1 and a Delta 44, and have been running the 5.10.00.0026 drivers since I got it a few months back, and have never seen the behaviour you describe. Our configs are very similar:

P3-1Ghz Asus P3B-F 440BX chipset
512mb RAM
Windows XP Pro
Delta 44 (no other soundcards)
Gforce 3 video card
NVidia Vanta secondary vid card (tnt2 chipset)
3com Etherlink III network card

Just out of curiousity, have you tried setting up a h/w profile where all unrelated devices are disabled (your net card, soundblaster, etc.) to see if this is a resource conflict?
 
Last edited:
Slack - great write-up!

Also, I ran the same test recording with WDM drivers on CoolEdit Pro 2.0 , and wound up with the exact same results. When i imported the delayed track recorded under sonar to cooledit, it actually lined up perfectly with the track recorded under the same buffer settings in cooledit. So we can add CoolEdit to the list of audio apps that exibit this problem.

At this point I'm assuming it is either the driver, or some kind of hardware/OS configuration problem both Slackmaster and I share in common. Just as a note, the midiman tech guy told me that the Delta drivers had been tested with both ntrack and sonar under WinXP with the motherboard I use (Asus A7v333).

Finaly, I had been using ntrack to quantify the delay. I was a little puzzled as to why SlackMaster's delay values were much longer than mine, so I decided to follow his steps of importing the files into WaveLab. When I did, I ended up getting the exact same delay times as he did - with 1.5ms under ASIO, and 10ms under WDM with 384 sample buffer size. I then tried the same thing in CoolEdit and got the same reading. So my inital measurements made in ntrack were off.

I'll update my webpage as soon as I have time.
 
heinz,

It actually does say in my writeup that I verified the results with 5.10.00.0027 in red text underneath my config. The results I posted were simply obtained using 5.10.00.0026 (I prefer 26 to 27).

I also verified these results on Win2k SP2, and an earlier version of n-Track.

This is not a hardware problem. No resource confict could be responsible.

You might not have noticed this problem for a couple reasons:

1) You don't have the problem.

2) You aren't recording using WDM.

2) You never checked! Realize that to see this amount of track offset you have to zoom in to the millisecond range. This is something that you might not really hear, depending on what you're doing, and it's certainly something you might not see, because 10ms of offset isn't going to be visibly noticable under normal working conditions.

bdemenil,

Cool, I'll add Cool Edit to my list as well. I am convinced that this is not a software problem. It's either WDM itself or the Delta drivers.

Slackmaster 2000
 
Slackmaster2K said:

You might not have noticed this problem for a couple reasons:

1) You don't have the problem.

2) You aren't recording using WDM.

2) You never checked! Realize that to see this amount of track offset you have to zoom in to the millisecond range. This is something that you might not really hear, depending on what you're doing, and it's certainly something you might not see, because 10ms of offset isn't going to be visibly noticable under normal working conditions.
Click to expand...


Hey sorry I missed the red text bit. And not to diminish the effort at all, your web page was very informative.

It's possible it is happening, being a drummer I'm freaking anal about timing stuff, so it would surprise me. But I'll perform the tests you did in Sonar and see what I come up with.
 
I requested to M-audio that they come here and join the discussion.
I suggest that a few of you also invite them so that we get thier attention. They have been here before, on occasion, and if I rem correctly, they were quite helpful in solving a clock problem someone was having.
Invite them yourself also, and lets see if we can do anything about this or not, and make it a thing of the past and get back to worrying about chicks.
Dig?
Peace.
 
Slackmaster

I know what u meant i just mentioned i changed it to 256 cuz previously i said it was at 512 but anyway I did zoom in, in sonar their is a lag I listen... its not audible except when looping u'll hear a slight pop

and i have no reason to put my buffer settings to 2000+ cuz'll they'll never ever be that high if its a problem wit buffer settings that high that is something thats irrelevant cuz it won't be that high

yall tried formating and clean install? could be a MS OS problem(something thats no surprise)
 
Teacher, I think what you're saying is that you have noticed the same problem. Did you see more delay at 512 than at 256? The only reason to test with the buffers all the way up is to see if you realy do have the problem - in this case the delay should be very pronounced and audible.
 
Actually this would not be a problem that a Windows reinstall would fix.

And I frequently have my Delta buffers at 2048 because I work with both ASIO and WDM applications at the same time. If you only work with WDM then the problem probably won't have a huge impact on you.

I would like to see a delta control panel with buffer settings for each driver model. I would also, of course, like to see this WDM problem fixed. Latency is a total non-issue when you're not doing live processing. Track offset, on the other hand, is an issue no matter what you're doing. The more the offset, the wider your range of phasing problems in the upper frequencies for one thing.

Listen, if this is not an issue for you then don't sweat it. It is, however, an issue; a real flaw. Now that I know about it I won't be blowing any more takes, but I also won't be working as easily. If it's correctable then it should be corrected.

Slackmaster 2000
 
Ok, I emailed Flavio (n-Track) and he got back to me. He uses a Delta66 on XP and doesn't seem to have this problem.

But here's the catch, he's using the initial WDM driver release from November of last year. Maybe I'll have to give those drivers a whirl.

Slackmaster 2000
 
Slack -
I just tested with the earliest available WDM drivers - 5.12.1.25 - released 11/2001 - I found that for me, the problem still occurs.

Ben
 
You must log in or register to reply here.
Back
Top