Hi Alejandro, nice to meet you too! Since I asked for a discussion, I better start with it right away :) The way I see it, the discussion is not so much about how to achieve low latency on the Windows platform but how to present this in a consistent way to applications. IMHO, the key points in achieving low latency and best performance are: 1) Processing should be completely event driven, triggered by the hardware driver. 2) Avoid using hardware positions or times, they don't have an absolute meaning when not related to an event. 3) Extra copies of samples are not that bad, the available memory bandwidth is enormous these days. Scather/gather techniques have more overhead and were designed with large transfers in mind. Although audio consumes a lot of I/O bandwidth also, the typical transfers to/from hardware are done in small bursts. My biggest objection against the current WDM/KS model is that Microsoft is trying to convert every audio card out there into a common virtual audio device. This may be great to support generic MultiMedia, it's not ideal for many audio applications and/or hardware. WDM/KS grabs the hardware for exclusive use and the API's available to a user-mode application are exactly the same as before, namely Wave I/O and DirectSound. Neither one of them is capable of operating reliably at very low latency. Many applications use DirectShow as the base model for their mixer environment but have to provide their own capture/render filters because the standard ones aren't adequate. To me, it seems logical to extend DirectShow into kernel mode, into the hardware driver. The current WDM/KS model works already in that direction but is bloated with too much overhead. And most importantly, the user-mode low latency DirectShow capture/render/proxy filters are still missing. They should be the common filters used in 3rd party applications. Even standard MultiMedia should be using these to create a "universal" audio experience. Once DirectShow is chosen as the common interface, certain pending problems can be solved in a straightforward way. Latency compensation for one, is automatically dealt with in a graph if timestamps are correctly maintained. Synchronizing streams, even across different hardware, is easier because of the timestamped transfers (common reference clock). I hope I didn't touch too many issues at once :) Dirk ****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.de/