M AUDIO sucks! Not my words btw..

I checked the german site and for a moment thought they had a newer driver, but no......sigh:( I´ll check it regularly and if I see an update, of course I`ll let you all know
 
yeah right now they appear to have the same drivers... but the german site always gets the driver updates WAY before the american site...
 
I don't think there has been much they can do about it.

I've been doing a bit of programming lately, and the way directX works is you create a sound buffer and a capture buffer separately. There's no way for the harware to sync the samples being read by the application with the samples being sent to the audio out since the application is already reading the capture buffer while it is feeding the sound buffer.

The oply thing they could really do is include a "defer capture up to latency" option in the control panel that throws away the first <i>n</i> samples of every capture.

I have noticed something called a fullduplexbuffer that I think is only available in DirectX8. I wouldn't be surprised if these issues went away with the next driver release.

I bet the ASIO model supports some kind of full duplex interface that allows hardware syncronization of the two streams.
 
Doug H said:
I've been doing a bit of programming lately, and the way directX works is you create a sound buffer and a capture buffer separately. There's no way for the hardware to sync the samples being read by the application with the samples being sent to the audio out since the application is already reading the capture buffer while it is feeding the sound buffer.

Forgive my ignorance, (i'm not trying to be sarcastic) but how is WDM related to DirectX? Anyway, I think the internal operation of these drivers is too complex for someone who is not acquainted with them - or with WDM audio drivers in general - to guess the specifics of how they operate.

What is sure, is that the driver, when operating correctly, either does the syncing itself, or provides information that allows the audio app to sync outgoing and incoming audio so that the two coincide in the application the same way as they do in the real world - ie - there should be almost no offset in newly recorded tracks. What small offset there is - due to imperfections in the model - should not change drastically depending on your buffering scheme.

There's no excuse for a driver which under some of its pre-set buffering schemes creates track offsets of >50ms . If, because of some shortcoming of WDM and winNT, they are unable to fix the problem, then they should document it.

By the way, if syncing is impossible while using DirectX, why do DX plugins work? They certainly don't introduce 10-50ms delays. If they did, every compressor, eq, ect, would also be acting as a delay - that would certainly sound funny.
 
Ok..I need some advice now :=) I just bought a Delta 66/Omni package mostly because of the great reviews from HR users!! Now this...
I plan on using it with Sonar 2 (WDM)
Do I need to return it now? It should arrive Tues from Sweetwater. I don't want to get stuck with problems. Any advice?

Steven
 
That's what I'm curious to know, too. I was plan to buy Delta1010. But after I found the thread about the driver problem, I don't know what dicision should I make.
 
I guess everybody post the same questions now. Coz me too, I want to buy a second 2496 and I am using Sonar.
So I'll better wait. :confused:
 
Ok... here's where I'm confused. These drivers have been out for several months (is that correct?) so how come this problem is just now being noticed?
I guess if it's just 2 or 3 ms (not a big deal) but if it's much more, I think it'll drive me crazy...especially now that i know it's there :=)


S
 
but how is WDM related to DirectX?
probably not at all, i don't know. But from reading this thread and what I've been learning ti seems to add up. I'd bet any card running in "WDM" mode is using direct X.

By the way, if syncing is impossible while using DirectX, why do DX plugins work?

No idea. I'd have to know what they do. And it's not impossible, it just has to be done in the application software, not the drivers, at least in earlier versions of directx from what I've seen. Plugins probably run against the buffer before it is read and processed by the card.

Anyhow, I don't really know for sure, it just looks very probable from where I'm sitting.
 
I have a suspicion that the offset is always there in respect to the DAWs timeline. Yesterday, I listened to a Sonar project containing midi and audio but my buffer latency was set at half the latency I had recorded at. The timing of the midi drums sounded worse than I remembered. A hunch made me reset the Audiophile buffer back to my usual 512samples and the track then sounded ok again. So I think audio is always playing late and milliseconds do matter. I might test this further. Anyone else?

BTW - I did check this with another card remember - Turtle Beach Santa Cruz - which is also wdm and this did not have this fault!
So it's not a general WDM or DirectX issue.

Jim
 
i've been thinking of putting a warning on my gear review site if i ever post up a review of an m-audio product stating that its customer relations are rancid. and, i love the audio buddy and the audiophile card.

steve
www.piemusic.com
 
I think I may have a "fix" for Sonar. Give it a try. I've only tested a short recording @ 44.1khz 16bit.
Make these settings in the Delta control panel...
Drivers - Independant. (dunno if this makes a diff' a hunch?)
Buffer = 64 samples (Yep, the minimum).
I unticked "prevent other programs access to control settings" on another hunch that maybe Sonar needs to do this in order to test the card properly.
Open Sonar and go to Options / Audio.
Run the Waveprofiler.
You ought to get a silly low latency of 1.5ms.
Move the latency slider up to something you know works on your system - I picked a safe 11.6ms.
Run your offset test.
I did the loopback recording via the waveout 1/2 left and recorded from monitor mixer left input and then panned the track hard right in Sonar (the original hard left). After exporting both tracks to .wav I opened it in Cool Edit Pro and measured the offset. It was ( my cep only reads out whole milliseconds) -
Snare roll please -

Just 1ms!

If you test by looping from analog to analog, my guess is you will get around 2ms offset.
Try it - fingers crossed.
The way I set up the Delta card for Sonar is the way RME suggest for their cards - sometimes I get ideas from other manufacturers who post relevant info on their sites if not m-audio. Curiously, STAudio say run the profiler first then set their cards panel to match Sonars profiles. Huh!
 
Jim Y said:
I think I may have a "fix" for Sonar. Give it a try. I've only tested a short recording @ 44.1khz 16bit.
Make these settings in the Delta control panel...
Drivers - Independant. (dunno if this makes a diff' a hunch?)
Buffer = 64 samples (Yep, the minimum).
I unticked "prevent other programs access to control settings" on another hunch that maybe Sonar needs to do this in order to test the card properly.
Open Sonar and go to Options / Audio.
Run the Waveprofiler.
You ought to get a silly low latency of 1.5ms.
Move the latency slider up to something you know works on your system - I picked a safe 11.6ms.
Run your offset test.
I did the loopback recording via the waveout 1/2 left and recorded from monitor mixer left input and then panned the track hard right in Sonar (the original hard left). After exporting both tracks to .wav I opened it in Cool Edit Pro and measured the offset. It was ( my cep only reads out whole milliseconds) -
Snare roll please -

Just 1ms!

If you test by looping from analog to analog, my guess is you will get around 2ms offset.
Try it - fingers crossed.
The way I set up the Delta card for Sonar is the way RME suggest for their cards - sometimes I get ideas from other manufacturers who post relevant info on their sites if not m-audio. Curiously, STAudio say run the profiler first then set their cards panel to match Sonars profiles. Huh!

thats not a fix at all... we'd all get about the latency if we ran with buffers at 64, but once you get plugins running and a track count, good luck getting stuff recorded at only a buffer of 64... the problem with the drivers is that the higher you set the buffer, the higher the latency... so just setting to a low buffer isn't a fix or workaround at all...
 
I have set the latency in Sonar if you read my description. It appears to me that Sonar manages it's own buffer and the one in the Delta panel ends up being additional and beyond Sonars knowledge.
There is no way my pc will record a second of audio with a 64 sample buffer and latency slider at minimum. But it works , I've already succesfully tested with few recordings and playing back complete projects.

If you want your problem solved you can try this or...
 
I can't successfully work in a 24 track project in WDM without at least a 256 sample delta buffer. It's odd though, anything higher than about 512 and I get dropouts.

Another problem with using a 64 sample buffer is that any ASIO application will not work at all. They really need buffer settings in the control panel for each driver model, especially ASIO and WDM which have completely opposite requirements. With ASIO you have one buffer setting which will usually be fairly high...with WDM you have two buffer settings and the delta setting needs to be low.

I wouldn't say that decreasing buffer settings is a "fix" to this problem, since it is already well-known that that the track offset is directly related to the delta buffer settings when using WDM.

You are correct though. Using WDM your software will manage its own buffers in addition to the delta's dma settings. Using ASIO, only the driver's buffers are used.

Slackmaster 2000
 
Yep, ASIO needs the buffer.
So M-audio really do need to go back to separate settings. They could also try actually posting updated info on how to set up their cards with the differant apps - there aren't that many. It's surprising there aren't referances to Windows 3.1 in their FAQs!
Haven't checked CEP yet - having too much fun with Sonar - I can open FX windows while things are playing without any stutters.
This is how it should be.

I'll repeat - Sonar doesn't want the Delta buffer.
You can set the performance with Sonars Latency slider - that is what it is for. If you need to increase Sonars buffers you can increase the "Buffers in playback queue" Each one extra above the default 2 doubles latency. I am not setting my latency to 1.5ms with the 64 buffer setting - I am using the Slider to set it to 11.6ms! The point is that changing Sonars buffers does not introduce track offset because Sonar knows what the latency delay is.
Maybe this is not a "Fix", in which case my dictionary is out of date.
Well, I'm more than happy now and it's thanks to RME who do know how to profile a card in Sonar.
 
All WDM applications work that way, you have two buffer settings to make, both of which do have an impact on your performance.

You're right though, m-Audio needs to wake up and start talking to its customers...enough of this "IRQ" and "ACPI" bullshit they blame everything on.

Slackmaster 2000
 
Here's the RME Sonar Setup article...
http://www.rme-audio.de/english/techinfo/conf_setup4.htm

You will note that after setting the minimum buffer size in the cards driver settings - all further adjustments are done in Sonar.
The thing it mentions with 24bit transmit set as "32bit right-justified" is an RME only issue. The Delta profiles correctly in this regard.

I've carried out a search of several audio card manufacturer sites - Apart from RME and STaudio - none provides information for set up with Sonar despite having WDM drivers.
Failures include...
Edirol
Echo
MOTU
...and, of course - M-audio.
 
Jim Y, I tried a similar 'fix' using ntrack, and found that with the 64 sample buffer, even with heavy buffering in the software, I can't work with large numbers of tracks using heavy FX. I think the driver buffers are important and cannot be completely circumvented.
 
Back
Top