Problem with WDM drivers for Delta

  • Thread starter Thread starter bdemenil
  • Start date Start date
Ben, did you use the delta uninstaller before installing the new (old) drivers?


Slackmaster 2000
 
I'm not entirely sure that Flavio did the test right...I *think* he might have been routing via software. I've emailed him asking him to clarify.

It would be nice if a few other people could verify this. There's a procedure on my website (although it's kind of hard to follow). I'm especially interested in other soundcards.

Slackmaster 2000
 
Supposedly they running the test tomorrow at Midiman. I'd like to see more people verify this too. You'd think more people out there are running this set-up.


Ben
 
my computer was supposed to be here anytime now frmo airborn express...as soon as that comes i'll do the test with NTRACK.
 
I'm back...
So did this die or what? Did M-audio run the test? How come they never showed up? Anyone else spoke with them?
Fill me in here...
 
sorry guys, i'm working on testing it out..lol

i cant even get Ntrack to run right. so i suppose i'll be reinstalling windows without ACPI...
wish me luck.
i'll try to test after i get it to run! lol
 
I'm still waiting on midiman. Seems I will have to re-explain everything to the tech they've assigned to the problem. In the mean time, has anyone else run the test? The more people evaluate this, the more weight it will put on them to resolve the problem.
 
I just talked at length to the midiman tech. He believes the problem is with the soundcard's IRQ. Says in order to use WDM, you must disable ACPI and manually asign the card a unique IRQ -as low as possible. Says midiman is currently working on a revision which will be more ACPI compliant.

Now, I know that Slackmaster ran the test with ACPI disabled, and that our results were the same. So I am a bit skeptical of the proposed solution. I don't realy have time to disable ACPI unless I know it will make a difference.

The midiman tech didn't try to duplicate the test. Instead he generated a midi clicktrack, synced it to an external drum machine, and recorded the audio off the drum machine - checking to see how much delay there was between it and the midi reference. He claims that under these conditions, his recording delay remains very small, and constant regardless of buffer size.

In my opinion this test doesn't address the issue. The issue is with recording audio over audio. Both audio playback buffering and audio recording buffering are involved. The problem seems to reside in communication between the driver and the software about how much to compensate for buffer size. In the tests run by Slackmaster and myself, it looks as if no compensation is occuring.

Basicly, midiman is not feeling motivated to realy look into this issue because only 2 people, Slack and myself, have reported it. So if more of you could check it out, that would be good. It takes 1 minute to set up, and maybe 30 min to perform.

Slack, the midiman guy wanted to know what IRQ your card is on, and if it sharing that IRQ with something else. I will email you his contact info.


Ben
 
Sorry to say I don't fully understand this thread, but I'm responding as a Delta 1010 user and if there's anything I can do to help (tests, submit questions to midiman, etc.) please let me know. :)
 
Oh for cryin out loud, I already gave these midiman guys my setup a couple weeks ago. Sigh.

My Delta 1010 is *alone* on IRQ 5 with ACPI disabled. The motherboard is a 440BX. It doesn't get more "standard" than this!

This is so not an IRQ issue I'm starting to get a little irritated. In the last three years I have only seen IRQ issues be responsible for audio mishaps in VERY VERY few cases, and none of them looked anything like this.

It also bothers me that they can't seem to figure out how to duplicate the test. This demonstrates a lack of understanding for both the product and recording in general.

Maybe we need to find a way to get right up to the driver developers?

For those who don't understand the test we've outlined, the concept is this:

When you hit record in your application, you hear the previous tracks playing, and you synchronize your playing to these tracks (e.g., you play your guitar to the drums). We are claiming that when using WDM drivers, the guitar track you record will be up to 50ms late compared to the drum tracks you were playing to.

To test this, you simply need to route an output to an input. It's simple, you're just recording the output instead of listening to it. If the recorded track is written late compared to the original, then you know that no matter how tight you try to play, you're still going to be stuck with this lag and the only way to compensate for it is to physically move each track you record.

Slackmaster 2000
 
They follow the usual protocal of tech support - try to find something to pin the blame on - either the customer or a 3rd party - preferably something not immediately verifiable. The guy actually changed what he was saying several times- first that what we are experiencing is normal - then back-tracking and blaming it on IRQs - also at one point saying our test is meaningless. His main arguement is that lots of people are out there using this, and that we are the first to complain. So could someone else with ACPI disabled please perform the test.


p.s.
It would help if the terminology wasn't so confusing. What it the correct name for what we are talking about- 'Recording Latency'?
 
Slackmaster2K said:
For those who don't understand the test we've outlined, the concept is this:

When you hit record in your application, you hear the previous tracks playing, and you synchronize your playing to these tracks (e.g., you play your guitar to the drums). We are claiming that when using WDM drivers, the guitar track you record will be up to 50ms late compared to the drum tracks you were playing to.

To test this, you simply need to route an output to an input. It's simple, you're just recording the output instead of listening to it. If the recorded track is written late compared to the original, then you know that no matter how tight you try to play, you're still going to be stuck with this lag and the only way to compensate for it is to physically move each track you record.

Slackmaster 2000
Click to expand...

Thanks for the brief Slackmaster. I'll give it a shot this weekend when I get the chance and let you guys know if I have the same experience :)
 
If you are routing your outputs through the monitor mixer, make sure the inputs are muted - else it'll feedback
 
I think the best term would be "track offset"...I used to refer to it as lag but that's more what you see when you have two devices not synching...not exactly what we have here. It's also not latency.

Ok Ben, I updated my web page with pictures of my current setup. I don't think it can be argued that I'm running ACPI or that I've got an IRQ problem with the Delta. In fact it's funny he mentioned it should be on "as low an" IRQ as possible, and it just happens to be on 5 :)

http://www.slackmaster2000.com/articles/WDM/wdmprob.html

Slackmaster 2000
 
Just an aside, the Midiman tester I talked to claims he can flawlessly record 24 tracks simultaneously (3 1010s chained - using WDM) all the while keeping his buffers on the lowest possible settings - 64 samples. All this in 96K 24bit audio. He says he never has any need to raise the buffers.
 
Just an aside, the Midiman tester I talked to claims he can flawlessly record 24 tracks simultaneously (3 1010s chained - using WDM) all the while keeping his buffers on the lowest possible settings - 64 samples. All this in 96K 24bit audio. He says he never has any need to raise the buffers.
Click to expand...

Ask him how the hell did he accomplish this!!!!!!What setup he has and bla bla bla. :D
 
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
Click to expand...

Teacher, i don't know if you're still monitoring this thread, but the track offset you experience will not change if you change the buffers within your audio app - only if you change them directly on the control panel. Even if you never have reason to set your buffers all the way up, it is worth trying - it makes the problem more obvious. While the problem is more subtle at the settings you would normally use, it may still be having a negative impact on your music.

Ask him how the hell did he accomplish this!!!!!!
Click to expand...
Says he has ACPI disabled w/ each card on its own IRQ. I didn't ask about the HD or the Proc.
 
You must log in or register to reply here.
Back
Top