Hi,

Ron Kuper wrote:

But ASIO isn't the only way around KMIXER. With the advent of Win32
Driver Model (WDM) Kernel Streaming (KS), the Windows O/S is indeed
capable of very low latency. WDM KS has a standardized device I/O
control set that's part of the Windows audio stack. KS makes it
possible to stream audio at sub 5-msec latency -- approaching 1 msec
latency -- using a direct interface to the "miniport" driver in the
Windows driver stack.



Please specify if you mean per fragment (buffer, usually 2) latency or total latency.
many soundcards don't even support 1msec buffers for example in the RME Hammerfall case (at 44kHz)
the minimum is 2 x 1.5msec buffers = 3msec total latency.
Even if I'm repeating myself over and over even professional audio magazines like the german "Keyboards"
get it wrong and proudly says "RME card is able to achieve 1.5msec latency (at max 50 CPU load, which is strange too)".


Returning to the virtues of WDM: while it's certainly much better than MME it's certainly not an optimal system otherwise
the Tascam guys that produce Gigastudio, would have dropped their own low latency driver model (GSIF) and would have
adopted WDM,ASIO which would ease the pain of integrating Gigastudio with other audio apps.
The other theory why they still use GSIF (now they even developed GSIF further by releasing GSIF2) because it would
be too time consuming (perhaps they need to rewrite a large section of code to adapt Gigastudio to WDM/ASIO) .
I can understand that at the time when the first version of Gigasampler was developed WDM was not a viable option
(not sure about ASIO) but right now IMHO if I wanted to develop an audio app I would try to avoid new driver models
at any cost. I think one of the best tradeoffs is simply writing VST plugins (or using other plugin APIs) because hosts are usually
optimized for low latency audio I/O, can use whatever audio drivers they wish/need and reinventing the wheel for the
audio application developer is simply a waste of time.
Not to mention that using a plugin API you get perfect integration in a virtual studio.


The fact is that on windows there are too many audio APIs and every vendor is trying to push their own ones which causes
fragmentation, interoperability problems (some drivers conflict with others) etc.
If WDM is really that good then from a logical point of view it would make sense for all audio application developers to drop
their proprietary drivers and go the WDM route. WDM drivers are shipped with every audio card, be it a consumer or pro-audio
card so I don't see why WDM should not become the only driver model standard in the windows pro audio world.


As said I'm not an expert in low leven windows drivers but I guess WDM is still not perfect so audio apps producers
prefer to go their own way to squeeze out the maximum from the hardware (especially for virtual instruments it's very important
to achieve low latencies so that the instruments can be played live).


Anyway regardless of the performance of each driver model I still see other low latency show stoppers on windows:
binary drivers for graphic cards, network cards and other peripherials: in some cases they disable IRQs for a relatively
long time (even if it's only a few msec it can be fatal for low latency audio), or cause high CPU usage bursts for a short period
of time.
In a normal desktop system (even when playing video since video plays usually at 25/30 FPS (30-40msec frame duration) is immune
to CPU bursts/IRQ disablings which last <30msec) you won't notice any problems in case the drivers cause those CPU spikes/IRQ disabling
but in a low latency audio application you hear pops and clicks and both as a developer and as an end user you have often hard time
to figure out what is causing these pops and clicks.
And since there are tons of different types of hardware, graphic cards, etc around it's often problematic to predict these problems in advance.
For example buying a PC optimized for audio needs quite good hardware knowledge and you often need to ask (or research on the web)
if a certain card is low latency friendly.
Pity that it's often not the hardware's fault but the driver's fault and in many cases the companies producing those drivers are not
interested to fix/improve them to make them low latency friendly.
Their main market is probably not the pro audio user (which is a very small market compared to the overall PC market) and requests
for driver improvement are therefore often ignored.
At least on Linux developers can optimize and fix all by themselves (ok there are some exceptions like the binary nvidia drivers but
there is always the open source driver, which despite the lack of OpenGL is still pefectly suitable to run audio apps).


cheers,
Benno
http://www.linuxsampler.org




Reply via email to