Linked by Thom Holwerda on Mon 19th Sep 2005 20:33 UTC
Windows In previous Windows releases, the entire audio stack ran in Kernel space. Vista will put an end to this. "The first (and biggest) change we made was to move the entire audio stack out of the kernel and into user mode. Pre-Vista, the audio stack lived in a bunch of different kernel mode device drivers, including sysaudio.sys, kmixer.sys, wdmaud.sys, redbook.sys, etc. In Vista and beyond, the only kernel mode drivers for audio are the actual audio drivers (and portcls.sys, the high level audio port driver)."
Order by: Score:
Good Idea
by Anonymous on Mon 19th Sep 2005 21:19 UTC
Anonymous
Member since:
---

As much as I hate microsoft, this is a good idea.

Kernel-based services should be used sparingly.

Reply Score: 2

RE: Good Idea
by MikeGA on Mon 19th Sep 2005 21:51 UTC in reply to "Good Idea"
MikeGA Member since:
2005-07-22

Indeed. Presumably this makes the system more stable. A faulty sound device/driver cannot crash the system?

However, does it mean you have to run seperate versions of the sound system for each user? More resource bloat?

Interesting that they say the old system is not good enough for Pro users. Sounds like they want a slice of this pie from Apple.

Kinda reminds me of a recent Microsoft advert where some girl breaks up with her boyfriend and decides to use the "world of possibilities with Microsoft Windows" to record a song about. Shame the advert doesn't explain any further; I'm yet to find a Windows machine that ships with a decent Audio app. Indeed, I've tried lots of different apps on both platforms, and am yet to find, other than Garageband, a cheap application that users can pick up and learn easily to record music.

Reply Score: 1

RE[2]: Good Idea
by corentin on Mon 19th Sep 2005 21:54 UTC in reply to "RE: Good Idea"
corentin Member since:
2005-08-08

> a cheap application that users can pick up and learn easily to record music.

Have you tried Audacity?

Reply Score: 1

RE[2]: Good Idea
by rain on Mon 19th Sep 2005 22:06 UTC in reply to "RE: Good Idea"
rain Member since:
2005-07-09

a cheap application that users can pick up and learn easily to record music.

then you havent tried this one
http://mackie.com/products/tracktion2/index.html

Reply Score: 1

RE[2]: Good Idea
by Ressev on Mon 19th Sep 2005 23:29 UTC in reply to "RE: Good Idea"
Ressev Member since:
2005-07-18

I've tried lots of different apps on both platforms, and am yet to find, other than Garageband, a cheap application that users can pick up and learn easily to record music.

Obviously you must not have tried ACID from which Garageband takes great license. It's been around since the last Millenium. The Pro version is expensive, but they have some stripped down versions that cost a mere $50 and do just as well for the amatuer. There is also, for the more adventurous, Computer Music's CM Studio which is free and can be found on any CD that ships with the magazine (well, it then costs $15). You get a lot of quality sound making tools as well as royalty free loops.

Audacity was also mentioned and is quite good.

Reply Score: 1

RE[3]: Good Idea
by Anonymous on Tue 20th Sep 2005 02:37 UTC in reply to "RE[2]: Good Idea"
Anonymous Member since:
---

What are all of you people blathering on about?! All you need is sndrec32.exe:

http://www.albinoblacksheep.com/flash/noises.php

Reply Score: 1

RE[4]: Good Idea
by Anonymous on Tue 20th Sep 2005 02:56 UTC in reply to "RE[3]: Good Idea"
Anonymous Member since:
---

Waahhhoooo!!! This seriously rocks!.

Reply Score: 0

RE[2]: Good Idea
by Anonymous on Tue 20th Sep 2005 01:52 UTC in reply to "RE: Good Idea"
Anonymous Member since:
---

Cheap audio app for recording that is intuative and easy to use and works on OS-X and Windows XP = Tracktion 2

Try the demo and see what you think. I've used Logic, Cubase SX and they can't compare to ease of use and price.

Reply Score: 0

RE[2]: Good Idea
by ma_d on Wed 21st Sep 2005 00:38 UTC in reply to "RE: Good Idea"
ma_d Member since:
2005-06-29

"Indeed. Presumably this makes the system more stable. A faulty sound device/driver cannot crash the system?"
Correction. A faulty sound/device driver cannot crash the system in as many ways. I.E., much of what it does will be out of kernel space, but some of what it does still lies there: I think those sort of bugs should be more obvious to flesh out.

Reply Score: 1

RE: Good Idea
by Anonymous on Tue 20th Sep 2005 00:04 UTC in reply to "Good Idea"
Anonymous Member since:
---

As much as I hate microsoft, this is a good idea.

Agreed -- to a point. (Personally, I don't hate them. I do avoid them, though, just as I would avoid other repeat offenders.)

Reply Score: 0

v this is an unHERD of idea
by Anonymous on Mon 19th Sep 2005 21:25 UTC
RE: this is an unHERD of idea
by rain on Mon 19th Sep 2005 21:30 UTC in reply to "this is an unHERD of idea"
rain Member since:
2005-07-09

Yeah, I wonder who that could have BEen.

Reply Score: 1

RE: this is an unHERD of idea
by corentin on Mon 19th Sep 2005 21:46 UTC in reply to "this is an unHERD of idea"
corentin Member since:
2005-08-08

> Hrmm... I Gno someone had to have this idea before, right?

In fact, this is not even an old idea : everybody wants to bring the whole audio stuff out of the kernel, since the beginning. The problem is that it brings a lot of latency issues.

Audio in the kernel is not a problem, as long as the drivers do not contain run-time errors.

Reply Score: 1

RE[2]: this is an unHERD of idea
by CPUGuy on Tue 20th Sep 2005 03:08 UTC in reply to "RE: this is an unHERD of idea"
CPUGuy Member since:
2005-07-06

The audio team is actually heavily focusing on low latency and glitch-free audio.

Reply Score: 2

by Lazarus on Mon 19th Sep 2005 21:48 UTC
Lazarus
Member since:
2005-08-10

Aren't the video drivers also supposed to be userspace in Vista as well?

Reply Score: 1

Not a microkernel
by Anonymous on Mon 19th Sep 2005 21:56 UTC
Anonymous
Member since:
---

Just because they're moving some functions out of the kernel into userspace, doesn't mean they're ripping off ideas from various microkernel systems. Some stuff just didn't belong there in the first place, even in the most monolithic of designs.

Reply Score: 1

RE: Not a microkernel
by Hugo on Mon 19th Sep 2005 23:37 UTC in reply to "Not a microkernel"
Hugo Member since:
2005-07-06

"Just because they're moving some functions out of the kernel into userspace, doesn't mean they're ripping off ideas from various microkernel systems. Some stuff just didn't belong there in the first place, even in the most monolithic of designs."

The NT kernel was at first a microkernel. It became sort of an hybrid when they started movind stuff to kernel space. And that kernel space not the kernel itself. The architecture is actually quite brilliant, Dave Cutler did a great job. It's not just a gigantic image blob loaded on boot, and it's more expandable than just dynamically linking more code (modules) to the blob.

Reply Score: 4

RE[2]: Not a microkernel
by kaiwai on Tue 20th Sep 2005 05:54 UTC in reply to "RE: Not a microkernel"
kaiwai Member since:
2005-07-06

Hugo, not all of us are as dense as GWB; we know there is a difference between kernel space/ring0 and the kernel itself - we also know the reasons WHY they were loaded into kernel space.

However, computers have now come to the point that the penalty of contextual switching should be so small, so meaningless, that there should be no need to load everything but the kitchen sink in kernel space, simply for the gain of a few seconds and slightly, unnoticable snappiness improvements.

Reply Score: 1

RE[3]: Not a microkernel
by corentin on Tue 20th Sep 2005 06:00 UTC in reply to "RE[2]: Not a microkernel"
corentin Member since:
2005-08-08

> However, computers have now come to the point that the penalty of contextual switching should be so small, so meaningless

A very small overhead, when called very often, is indeed a big overhead.

Reply Score: 1

RE[4]: Not a microkernel
by kaiwai on Tue 20th Sep 2005 06:03 UTC in reply to "RE[3]: Not a microkernel"
kaiwai Member since:
2005-07-06

Well, as long as you use them sparingly, then you shouldn't have a problem; I don't think the contextual switch would be unnecessarily high if video, audio and possibly the network stack was kicked out of kernel space.

Reply Score: 1

RE[3]: Not a microkernel
by Anonymous on Tue 20th Sep 2005 22:53 UTC in reply to "RE[2]: Not a microkernel"
Anonymous Member since:
---

YEs, you know gwb very well, right? Try to keep your political opinions to yourself...they are not appreciated on a tech/computer forum.

Reply Score: 0

RE[4]: Not a microkernel
by Anonymous on Wed 21st Sep 2005 04:01 UTC in reply to "RE[3]: Not a microkernel"
Anonymous Member since:
---

oh come on.. who could be offended by the truth.. the guy (gwb) is an idiot..

Reply Score: 0

RE[5]: Not a microkernel
by Anonymous on Wed 21st Sep 2005 04:01 UTC in reply to "RE[4]: Not a microkernel"
Anonymous Member since:
---

I cant believe the retards in this country voted him in again

Reply Score: 0

v Holy Crap...
by Anonymous on Mon 19th Sep 2005 22:06 UTC
v Microsoft learning from Linux
by Anonymous on Mon 19th Sep 2005 22:30 UTC
RE: Microsoft learning from Linux
by re_re on Mon 19th Sep 2005 22:49 UTC in reply to "Microsoft learning from Linux"
re_re Member since:
2005-07-06

I really don't think Vista developers code any worse or any better then OSS developers do. They code the way they are told to code. In fact I would venture to say that most of the problems that MS has are not because of poor coders, it is because of poor design concept and a poor policy on security. (although I believe the latter is slowly changing)

remember...... proprietary software developers tend to be the (at least in part) the people that also do development for the OSS world.

Reply Score: 2

rayiner Member since:
2005-07-06

I think the problem Microsoft has with regards to code quality is that they use the "thousands of mediocre coders" model, instead of the "handful of excellent coders" model. DirectX has over a thousand people hacking on it. It's track-record has been, well, mediocre. Windows NT was designed by a core team of a couple of dozen people. To this day, the NT core is the most technically sound product Microsoft has ever released.

Reply Score: 4

RE: Microsoft learning from Linux
by rain on Mon 19th Sep 2005 23:07 UTC in reply to "Microsoft learning from Linux"
rain Member since:
2005-07-09

Well, configuring a multichannel audio interface in Windows is a piece of cake. In linux it's, unless you are lucku, pure hell.
Now if only Linux developers would be able to create ONE SINGLE media framework that works and is easy to deal with.
Even Haiku's got one.

Reply Score: 3

DigitalAxis Member since:
2005-08-28

The worst part is, I had dmix set up, and then... it broke, or something. Stopped working, even though the files were in the right place.

At least Ubuntu comes with ESD by default; if only Kubuntu could use ESD so you didn't have to switch all apps to ALSA to get them to have sound at all...
(or maybe just start ESD while in Kubuntu? I'm not sure)

Reply Score: 1

v IE in, sound out?
by Anonymous on Mon 19th Sep 2005 22:36 UTC
RE: IE in, sound out?
by sappyvcv on Mon 19th Sep 2005 22:49 UTC in reply to "IE in, sound out?"
sappyvcv Member since:
2005-07-06

IE isn't in the kernel. You are slightly confused.

Reply Score: 1

RE[2]: IE in, sound out?
by Bending Unit on Tue 20th Sep 2005 04:57 UTC in reply to "RE: IE in, sound out?"
Bending Unit Member since:
2005-07-06

Since when has that stopped anyone from posting here? ;)

Reply Score: 1

BAD idea
by Anonymous on Mon 19th Sep 2005 22:58 UTC
Anonymous
Member since:
---

Windows has never been known for good audio quality. By moving much of the audio drivers out of the kernel, they are going to add unpredictable (and large) latencies to the audio stack, which will only make audio performance worse. I suppose it won't matter much if you are running Vista on a 2% utilized quad-core 4GHz P5, but as soon as your CPU utilization hits 100%, your audio quality will go completely down the drain.

BAD idea for Microsoft, but a very good outcome for Linux (which uses a beefy kernel-level Alsa system and a lightweight dmix or jack layer on top).

Reply Score: 0

RE: BAD idea
by diegocg on Mon 19th Sep 2005 23:08 UTC in reply to "BAD idea"
diegocg Member since:
2005-07-08

No, it doesn't looks that to me.


Read again: "re-Vista, the audio stack lived in a bunch of different kernel mode device drivers, including sysaudio.sys, kmixer.sys, wdmaud.sys, redbook.sys, etc. In Vista and beyond, the only kernel mode drivers for audio are the actual audio drivers (and portcls.sys, the high level audio port driver)."


It looks to me that they had too many stuff in the kernel. In linux, alsa has pretty much just the audio drivers - just like vista. It looks like in previous releases, many of the stuff that linux has on userspace (their dmix equivalent, etc) was on kernelspace which makes it ugly


IOW: Windows people seems to be cleaning up the windows kernel, which is a Good Thing (TM)

Reply Score: 3

RE: BAD idea
by Anonymous on Mon 19th Sep 2005 23:14 UTC in reply to "BAD idea"
Anonymous Member since:
---

It's funny, but what Microsoft is doing with Vista is what BeOS has been doing for a long time. In BeOS, the typical way to do things is to have a very low-level driver, and then use accelerants in userspace to do all the higher level processing. This is done for sound drivers, network drivers, video drivers, and most other types of drivers, too, in BeOS. While the old NetServer being all in userspace except for the lowest level driver blowing chunks for throughput, it seems this model of operation has worked quite well for BeOS, so it isn't beyond possibility that Microsoft may be able to make this worthwhile.

Reply Score: 2

RE[2]: BAD idea
by diegocg on Mon 19th Sep 2005 23:44 UTC in reply to "RE: BAD idea"
diegocg Member since:
2005-07-08

"In BeOS, the typical way to do things is to have a very low-level driver, and then use accelerants in userspace to do all the higher level processing"

This is done for pretty much every OS out there - linux certainly does it except in some places like the tcp/ip stack. Look at libusb for example: USB drivers in userspace. X.org's DRI....this is a "put policy in userspace" kind of design, it's not beos or microsoft who invented it.

Reply Score: 1

RE[3]: BAD idea
by Anonymous on Tue 20th Sep 2005 01:16 UTC in reply to "RE[2]: BAD idea"
Anonymous Member since:
---

Never once did I reference anything that stated BeOS (or any other OS, for that matter) was the first to do it: I used BeOS as a great example of a system that not only has done what Vista is supposed to do, but blows other platforms (including Linux) out of the water with low latencies for sound.

That being said, it'll be interesting to see if Microsoft has changed things enough to make interrupt handling have less overhead than the last time I looked at writing device drivers, where the driver model included a lot of deferred procedure calls at different interrupt levels. In comparison, BeOS has a much simpler driver model, much closer to the typical Unix-ish driver model. Which model is better, and in which circumstances? Well... let's let reality make itself evident there ;)

Reply Score: 0

RE: BAD idea
by CPUGuy on Tue 20th Sep 2005 03:11 UTC in reply to "BAD idea"
CPUGuy Member since:
2005-07-06

I reccomend heading over to Channel9 and watching the Vista Audio Team interview.

Reply Score: 1

RE: BAD idea
by nimble on Tue 20th Sep 2005 06:40 UTC in reply to "BAD idea"
nimble Member since:
2005-07-06

I suppose it won't matter much if you are running Vista on a 2% utilized quad-core 4GHz P5, but as soon as your CPU utilization hits 100%, your audio quality will go completely down the drain.

Ever heard of task priorities?

Reply Score: 2

RE[2]: BAD idea
by Anonymous on Wed 21st Sep 2005 01:41 UTC in reply to "BAD idea"
Anonymous Member since:
---

This thread is proof that most of you should never design and/or implement any kind of system. There are reasons that they had to go into the kernel in the past, and now, years later, those reasons don't apply anymore, so they've moving most of the audio out of the kernel.

Reply Score: 0

RE[3]: BAD idea
by Anonymous on Wed 21st Sep 2005 01:46 UTC in reply to "RE[2]: BAD idea"
Anonymous Member since:
---

I take that back, some of you actually have a clue. That'll teach me to read the second half of the thread first ;)

Reply Score: 0

OSS already does a lot of Vista's audio
by 4front on Mon 19th Sep 2005 23:44 UTC
4front
Member since:
2005-09-19

For those of you who watched the video, I invite you to check out http://www.opensound.com/virtmix.html - OSS does per-application volume control, per-application vu-metering and ossxmix and /dev/sndstat shows what app is running on which channel. We did this back in 2001 ;)

On top of it we have an RIAA-curve equalizer (yes the very same evil RIAA did some interesting research back in the 60s and 70s), fidelity enhance and stereo image enhance. Vista doesn't give you a system wide equalizer.

However I do not think that removing mixing from the kernel to user space necessarily works better. All it does is prevent a bug in the mixer from crashing the kernel. They talk about glitch-free audio and low latency audio but that really depends on

Reply Score: 3

reason
by Anonymous on Mon 19th Sep 2005 23:52 UTC
Anonymous
Member since:
---

I guess the only reason will be that it's simpler and (relatively) more performant to keep the drm'ified music "trusted" via the TPM having to care for a distinct set of libs and interfaces, instead the whole kernel.

Reply Score: 0

v ...
by Anonymous on Tue 20th Sep 2005 00:04 UTC
We have this for years already...
by Anonymous on Tue 20th Sep 2005 00:36 UTC
Anonymous
Member since:
---

MorphOS has it for years already. Don't know why it's worth a news item ;-).

Well, not a bad decision, but I guess the Vista will provide a big overhead, so expect latencies.

Reply Score: 0

Wow, the Be zealots come out in droves...
by Bascule on Tue 20th Sep 2005 03:38 UTC
Bascule
Member since:
2005-07-06

The NT kernel was at first a microkernel. It became sort of an hybrid when they started movind stuff to kernel space. And that kernel space not the kernel itself. The architecture is actually quite brilliant, Dave Cutler did a great job. It's not just a gigantic image blob loaded on boot, and it's more expandable than just dynamically linking more code (modules) to the blob.

THANK YOU! I think what these Be zealots are forgetting is the reason Microsoft moved away from a microkernel in the first place: performance.

I mean seriously, start up an FTP server on BeOS and try to grab a file. The entire OS chokes! Yes, pervasive multithreading and a microkernel make for a snappy GUI experience, until the system needs to do something I/O intensive. Then the whole thing just chokes. Microkernels are bad for I/O, and ultimately you end up taking something that can run 100% in kernel context, like, say, a sendfile() accelerated file transfer, and throw in a ton of context switches. Think what's happening with FTP. Your data goes:

Disk (Kernel) -> VFS (Userspace) -> Message Queue (Kernel) -> FTP Server (Userspace) -> Message Queue (Kernel) -> Network Stack (Userspace) -> Ethernet Driver (Kernel)

All those context switches are downright unnecessary, as has been proven by all the operating systems which have garnered mainstream support, like Windows, Linux, *BSD, Solaris, etc. who can accomplish this completely in kernel mode.

Yes, I sure do enjoy an operating system where I can share files at the same time I'm doing something else. That's really awesome.

Reply Score: 4

rayiner Member since:
2005-07-06

Microkernels are bad for I/O, and ultimately you end up taking something that can run 100% in kernel context, like, say, a sendfile() accelerated file transfer, and throw in a ton of context switches.

To be fair, it's more appropriate to say that G1 microkernels are slow for I/O. G2 microkernels (like L4) have put up some very impressive numbers in I/O performance, largely because of massive reductions in context-switch latency, along with extensive use of page-mapping to pass data around.

Reply Score: 3

Anonymous Member since:
---

I mean seriously, start up an FTP server on BeOS and try to grab a file. The entire OS chokes! Yes, pervasive multithreading and a microkernel make for a snappy GUI experience, until the system needs to do something I/O intensive. Then the whole thing just chokes. Microkernels are bad for I/O, [...]

I haven't (succesfully) booted into BeOS in two years, but I'm not sure that it chokes for the reason you describe. Net_server is very bad at handling its memory while transfering files. Perhaps even leaking it; your memory would fill up in no time.

_V_

Reply Score: 0

hraq Member since:
2005-07-06

I have tried zeta 1 final and found that LAN transfer was anemic at best until the Tracker (Like windows Explorer) Crashed completely and even restarting it was not enough to correct the unresponsive GUI. So yes it might be non pervasive in networking.

Reply Score: 1

Performance through the years
by Marcellus on Tue 20th Sep 2005 06:20 UTC
Marcellus
Member since:
2005-08-26

It seems a lot of people here forget some very basic stuff.
Some things that were done "back then" were done for performance reasons. What worked "best" back then is not the same as what works best today.

Algorithm A for doing one thing may be O(n) and algorithm B may be O(n^2). Depending on how hard they are to implement on the system you currently have available, the best choice might actually be to use B for it. And that's not even considering the constants. A may be better for 1% of the cases that users will ever encounter, while B is better for the rest. Does that mean you should use A just because it is better in theory?
Of course not.

The same principles apply here really. What worked back then maybe wasn't the best design they could muster up, but a design that was easy to get fast enough.

Reply Score: 1

RE: Performance through the years
by Anonymous on Tue 20th Sep 2005 22:55 UTC in reply to "Performance through the years"
Anonymous Member since:
---

It seems a lot of people here forget some very basic stuff.
Some things that were done "back then" were done for performance reasons. What worked "best" back then is not the same as what works best today.
---------------------------------------
What do you mean by "better"?

Reply Score: 0

UNIX, 30 years later...
by Anonymous on Tue 20th Sep 2005 06:52 UTC
Anonymous
Member since:
---

Oh, hell!
The guys at Microsoft are implementing a more prowerful consolle; they are saying that a more modular system with less critical points, depending to what is installed due to the destination use, is better than a big integrated system; they are saying that a more *x-like object right and access management will be more secure...
finally they are understanding the word "micro" in MICROkernel, since they use one...
Are they trying to mimic *x or what else???

Reply Score: 0

What took them so long?
by hraq on Tue 20th Sep 2005 07:45 UTC
hraq
Member since:
2005-07-06

This is a very good move from MS, but so late; combined with task scheduling we will not notice any problems from sound subsystem; if CPU utilization reaches 100% and you want to use audio it would stop you from executing the application that requested it. The same would be to HDD access. "This is like if you don't have coins then you cannot play the game". Anyway Vista looks promising but Security and GUI mess are down-grading it. We will see what the future will bring!

Reply Score: 1

Wasn't this moved _in_ after NT 4?
by Anonymous on Tue 20th Sep 2005 09:09 UTC
Anonymous
Member since:
---

I seem to remember that a lot of stuff was moved into kernel space during the switch from 4.0 to 2000. Coincidentally, after 4.0, I always felt audio to be flaky: in 4.0, WinAmp would continue playing in every situation. Even if the GUI had completely frozen, Winamp would play on. In 2000, it seems possible to get every audio app to skip by just maxing out the CPU. And the CPU is way better than the K6 I had for NT...

Reply Score: 0

n4cer Member since:
2005-07-06

NT4 was actually the start of moving parts of some subsystems into kernel space. GDI was moved there in NT4.

Reply Score: 1

Faulty output
by Anonymous on Tue 20th Sep 2005 22:49 UTC
Anonymous
Member since:
---

Hope this will stop the (albeit rare) issue of having a faulty soundchipset/driver write raw sound output directly to the HD.

Reply Score: 0

acid express
by Anonymous on Fri 23rd Sep 2005 22:33 UTC
Anonymous
Member since:
---

you can get a free version of acid on the sony website....

Reply Score: 0