OSNews

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.

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

Have you tried Audacity?

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

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.

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

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

Waahhhoooo!!! This seriously rocks!.

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.

"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.

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.)

Yeah, I wonder who that could have BEen.

> 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.

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

"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.

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.

> 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.

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.

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

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

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

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.

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.

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.

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)

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

Since when has that stopped anyone from posting here?

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)

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.

"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.

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

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

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?

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.

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

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.

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_

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.

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"?

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