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.