“Charles recently caught up with seasoned Niner, Larry Osterman, an SDE and 20 year Microsoft veteran, and Elliot H Omiya, a Software Architect and audio guru, to dig into the innerworkings of Vista’s updated Audio Stack and new user mode API. Much of the guts of Windows audio have been moved up into the land of the user and this has consequences for both Windows audio developers at the API level and for Windows at the general programmability, reliability and stability levels.”
Cool, he’s wearing a KZSC shirt!
Anyhow, Windows is due to an audio system overhaul. BeOS gave us a glance at what audio APIs could look like with the media kit, then Apple came with CoreAudio, with Windows being left behind.
This is not about sound on vista but about moving the sound stuff out of the kernel. That’s good for developers but bad for users since it’l impact real-time audio performance and increase latency. Good for developers since they can test their drivers and even if they are buggy they wont crash the system. In my opinion it’s better to have sound staff in kernel for performance reasons and just avoid using buggy drivers/cards and dont buy them so the manufacturers will have to fix their drivers. If the sound stack will become user-mode based the stability of the os overall will improve and the quality of the drivers will decreas for lots of low-end cards since they can now afford to write buggy drivers if that wont make the os unstable. High latency because of user mode will also increase the likehood of sound artifacts in cheap a97 codecs.
Note the potentially nasty, but quite interesting technique they have of mapping the DMA memory space of your soundcard into usermode. The user-kernel transition won’t create latency. One thing I’m wondering about based on their whiteboard architecture diagram is what they’re going to do with cards with hardware mixers… just ignore them and do it all in software?
About the buggy drivers… the sound card manufacturers will still be writing their drivers in kernel mode, so you still gotta fear Creative’s wonderful programming staff. Their mixer and effect logic would go in User Mode.
“One thing I’m wondering about based on their whiteboard architecture diagram is what they’re going to do with cards with hardware mixers… just ignore them and do it all in software?”
Possible that for this API, mixing happens in software, where DirectX games get hardware mixing. I would assume that pro audio users prefer high-quality software mixing, where gamers don’t give as much for hi fidelity than for fps.
Mapping the DMA memory range of the sound card into user space cannot cause a system instability in the worst case: all it can do for an undesired side-effect is if the application that happens to have it mapped into its address space writes random garbage in there.
As long as the only things mapped into user space are sound buffers without memory-mapped configuration switches, nothing too horrible can happen. If, however, the resources that were mapped consisted of anything that could affect control of the device itself, then that would be a potential minefield.
The one situation where you might fear (if you don’t know how it works) is when the audio hardware is capturing data: then it is important that the memory mapping into user space is correct. However, that’s something that would be controlled by the audio stack, and mapped very carefully by other than the device driver itself. This in actuality is no less safe than what happens now, because a sound card driver is always working in kernel space, where incorrect mapping will blow away something.
The performance isn’t likely to be hurt much, if any, by this: BeOS has always (at least version 4.0 and up, if not before) handled audio in this sort of fashion, and had the lowest latencies for audio. Granted, there’s more than one thing involved in the determination of latency, but they proved it can be done.
Jonathan Thompson
I’m pretty confident that the DMA memory space is mapped into the Audio Engine service which would be running as LocalSystem inside a svchost. I wonder how the WASAPI does interprocess communication fast enough… The session “streams” are probably either named pipes or shared memory. This architecture seems pretty interesting… I wonder what Avalon’s like on the inside.
Performance won’t be affected, surely not by a noticable ammount. They are doing the same thing with graphics drivers, which would probably degrade most noticably due to any performance penalties that may or may not exist. I don’t see them doing this to graphics if they weren’t confident about performance.
There is still a kernal-level component to the drivers IIRC, they’re just moving what they can to user space. I think the entire Vista Driver model is based on this concept for all(nearly all?) devices.
Please, that is the same rubbish that is used against X, but when the benchmarks come out, everytime X either beats or is within a flea’s pubic hair of the Windows/MacOS X result – User Space/kernel space is simply an excuse used by poor programmers to explain why their particular widget doesn’t perform as well.
If you’re getting crappy performance, shouldn’t the question lay squarely in the code that you wrote? or would that be resposibility for ones own algorithms?
wow Be inc must have made a fortune when it sold all those technology, sure having MS took 6 year to develop that with a legion of 60,000$/year employee must have cost less than 10MS.
ok, sarcasm is ended, you can resume your daily routine.
Aliensoldier