M AUDIO sucks! Not my words btw..

This just doesn't make sense. It's a *consistant* offset problem that doesn't need to occur. If every audio card suffers from the same problem (which I don't believe at this point), then it is WDM that is flawed.

Slackmaster 2000
 
Bdemenil...
I have never tried N-track.
What I have described only applies to Kernal Streaming apps such as Sonar - Can N-track use Kernal Streaming?
A few facts I have found out - hopefully they are true.
Under Win2k and Xp ALL drivers are WDM.
The driver can have several API interfaces for applications to use.
MME
ASIO
GSIF
EASI
KS (Kernal Streaming).
With MME, Windows own audio system handles the sound cards hardware and buffers using a software mixer called Kmixer - it has a fixed buffer of about 30ms at 44.1khz and for some bizzare reason cuts output levels by -6db. M-audios Delta panel has a tick box to use windows default buffer for MME applications.
ASIO/GSIF and EASI require additional driver support and it must provide the buffers.
KS requires the application to directly control and buffer the cards hardware. The upside of this is that Kmixer is bypassed and - from the app' - the buffer can be controlled to suit and you don't suffer the 6db cut. Just because a program will run with WDM drivers does not mean that it is using Kernal Streaming. A well written Win95 program will work in Win2k because the MME interface it expects is still present.
If N-track is MME, then it is dependant on Kmixer which may not be able to handle multitrack performance without outside help from the Delta panel buffer - it was only intended to act with the old AC97 codec system. Because of Kmixers limitations - Microsoft were lobbied to allow Kernal level access and actually agreed to provide it.
 
This is not an n-Track issue. It has been verified in many low latency WDM applications, including Sonar, which you verified yourself.

As far as I know, n-Track was the first application to officially support kernel streaming WDM when the whole kmixer issue was finally fixed (back in late 2000 if I remember correctly). It also supports ASIO, MME, and DS, all user selectable.

The kmixer issue is old news. Any application that supports "WDM" these days means low latency WDM, not MME. There has always been a distinction.

Slackmaster 2000
 
not to beat a dead horse:=) but has anyone heard anything from MAudio regarding this problem? (I mean anything besides, you have IRQ conflicts etc, ?) I just bought a Omni package and don't want to keep it if this is not gonna be workable. I am using Sonar 2 so ASIO isn't an option. Any help is appreciated. I have very little $$ so I need to make the right decision the 1st time :=)

S
 
p.s.

I sent Maudio an email regarding this...as a potential customer; so far no response...surprise, surprise...:=)


S
 
Don't try communicating with maudio via email - you may have to wait a month for a reply - or you may never get a reply. The best way is to call.

As far as the track offset problem. I've talked to three different people there, and none of them could grasp the significance of the problem. The first answer I always get is that this behavior is perfectly normal. Then that the test performed by Slack and myself is inherently flawed (they claim it creates a feedback loop - which it clearly doesn't if it is set up correctly). Finally they will fall back on IRQ as a last resort. When pressed further, they say they will refer me to someone else, and I will get called back. 2 months later, I am still awaiting that call. Each of the tech reps I have talked to have followed exactly this pattern - the same person has even repeated it in 2 different conversations. They seem to have no problem, over the course of a conversation, jumping from one excuse to another. They have yet, after 2 months, to even test for this issue. As of right now, I think they are denying any problem exists.
 
Sorry. Using WDM drivers does not ensure Kernal Streaming in the sub 30ms latency sense. Kmixer is Kernal Streaming but has a fixed performance not suitable for a modern DAW.
If N-track does support KS - then it must have it's own buffers to control performance as Sonar does - it should work with the Delta buffer at minimum - if not, then either N-track has a problem or your system does. It really is the applications responsibilty to provide Kernal level support - not the card vendors driver.
I have tested my old CoolEditPro (V1.?). The Delta drivers "...use MME Defaults" is ticked and the Delta buffer left at 64 and this old MME/Direct Sound (Yes, I forgot Dx in my last post - in WDM it is a parallel path with MME into Kmixer) app' performs as it should. There is definately a 6db cut compared to Sonar proving that it is going through Kmixer.

So, Does the Delta driver have a problem?
Yes and no. They are doing no differant to what RME (considered the most professional audio card manufacturer) are doing as far as I can tell. But I think that the Delta buffer is in the wrong place.
It is always there and I suspect is located at the deep kernal level of the driver code. It should only be needed by APIs other than MME/Dx/KS. However, being present where it is, at least you can use it as an extra buffer to get you out of trouble. It's unfortunate that it's existance is not recognised by the DAW app', hence the offset problem. However, it's also the DMA buffer. It needs to be close to the pci interface, so where else could they put it?

I don't deny that this is an issue. I can't bring myself to completely blame M-audio until I see that other cards with user DMA buffers have the same problem. It may be an unavoidable impact of Microsofts driver model - it won't be the first time that their efforts to provide "Simple, single model technologies to ease application development" have backfired on us.

Even with an offset down in the 1ms region, there could be problems. If monitor spill gets in then you will suffer comb filtering problems as already mentioned. It should be possible to get absolute, sample accurate, alignment - this has always been the claim of DAW manufacturers since the Latency issue first arrived with real-time plugins. "No matter what the latency is, your recorded tracks will be in perfect sync". Yeh, right.
I'm still really keen to know how other "Pro" cards perform in this respect but people seem unwilling to try the simple test. I'm hoping that Martin Walker (Sound-onSound magazines pc music guru) will take an interest in the posts we are putting in the SoS pc forum. So far, he has remained silent on the issue.

Most of what I "think" I know of WDM driver architecture comes from this article...
http://www.cakewalk.com/DevXchange/audio_i.asp
...which despite being copyright 2002 seems to have been written 2 years earlier - before MS made allowance for direct kernal streaming. The last diagram on page 2 provides a fairly clear picture.

I'm going to try to E-mail M-audio again. How to describe the problem?
"Direct Sound, MME and Kernal Streaming applications do not recognise the latency of the Delta DMA buffer. This buffer adds a constant offset time to audio record and playback that a mulitrack program is not aware of and leads to sync problems between consecutive recordings and midi tracks which should be "sample accurate"
Too technical for them?
 
Everything is too technical for them. We have at least two websites up now with freakin PICTURES but they still don't get it.

As I've stated on my site, I am not blaming m-Audio for the problem, because you're right, it may be a WDM problem. However, I and many others are getting a little angry that they don't respond. If they were to say, "this is a known issue that is out of our control, here is how to work with it", that would be fine. I would also like to see seperate controls for WDM and ASIO, as they require settings at oposite ends of the spectrum, and many of us mix both WDM and ASIO applications....not at the "same time" of course, but having to reset the delta dma buffer and restart ASIO apps every time we switch is stupid.

I am also not arguing that WDM does not guarantee KS. Whenever we deal with a microsoft technology, we are forced to deal with lots of ambiguity in the terminology we have to work with. ( "Will my DX plugins still work with DX 8.1?" is a great example ) When we talk about low latency WDM support at the application level, not the driver level, we "should" always be talking about kernel streaming at the application level and we should always be able to assume that we're talking about "real" low latency. Of course assuming things is dangerous, I realize that. I guess I haven't come across one example of an audio application boasting WDM support that didn't offer low latency WDM support, but my experience is limited. CEP for instance, which doesn't support low latency WDM, doesn't mention anything at all, it just says "requires soundcard." Yes n-Track has its own buffers when using WDM, and yes it is possible to achieve < 10ms latency on my system using WDM. However, I still can't work with the delta dma buffers set to 64. It could be n-Track's problem, it could be some mystical problem with "my system", it could be anything.

You are right that even 1ms of offset could cause problems, although I'm not sure the exact extent of the problem. I don't usually attribute the phrase "sample accurate" to analog routing, which is really what our test entails. I would assume that some lag would be introduced no matter what whenever we leave the digital realm and come back. Maybe you can clear that up for me?

Slackmaster 2000
 
I've always assumed that when a card is being used the delay between starting an input stream and the buffer saying "got it" is measured by the DAW - maybe not.
A mistake - My CEP v1 is being used with the Deltas "use MME defaults" UNCHECKED. Checking it causes a tremendous delay plus crackles. Measuring CEP's offset in samples gives exactly 64 - my Delta buffer. This was a test using the delta monitor mixer so a-d converter latency (typically 32 samples I'm told) isn't relevant, but there is also a pci bus interface buffer on the card - in the region of 32 to 64 samples - this must be being correctly accounted for by the program.
I'm not sure if around 1.5ms offset really would cause a problem in practice - I'm told that at the speed of sound, it takes around 1ms to travel 1 foot, so monitor spill is never going to be exactly in sync anyway!
 
hmmm.... the offsets I'm measuring using CEP2 with WDM drivers are much bigger than would be cause by the driver buffer alone. Recording with a 64 sample buffer size, I measured a consistent offset of about 190 samples. I wonder why.
 
Well, if I test using an analog loop-back, the offset becomes 123 samples. To me, that means 59 samples are buffered by the combined D-a and A-d conversions. Using the Monitor Mixer as the record source should mean you only see the Delta Buffer offset. I think the Monitor mixer actually represents the driver software and goes nowhere near the actual pci card. Once I was sure the Delta buffer was causing the offset, I made all further tests the digital way to save me having to re-patch my board!
 
OK, just tried recording from the delta mixer. With a 64 sample buffer, I got an offset of exactly 64 samples (well I could be off by 2 or 3 samples, but I did count 64). When I was recording through an analog pathway, I got about 190 - which is roughly three times 64. Wonder why it works like that...
 
when did this problem start happening? i havnt recorded live tracks in a while but i had no problems before the summer!
 
Just for the record, a friend of mine got a 44, and I did a quick test recording of a drum kit and stereo keys using my 44 and his together (all 8 inputs). I recorded seven minutes 24bit with no problems (although there was a slight phasey sound which I put down to my drum mic positioning).

Nathan
 
PapillonIrl said:
Just for the record, a friend of mine got a 44, and I did a quick test recording of a drum kit and stereo keys using my 44 and his together (all 8 inputs). I recorded seven minutes 24bit with no problems (although there was a slight phasey sound which I put down to my drum mic positioning).

Nathan
Click to expand...

Well of course not - there wouldn't be any problem in that case. Please check out the description of the problem we're talking about at my page listed above.

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