Comments

@LordKain: In all honesty, without the language projections, the windows runtime is not really that fun to use. There are so many aspect of winrt that are simplified by the language projection - as a simple example, try programming a winrt app without using await/promises/ppl.

The strength of the language projections is that using the language projection takes what is nominally a fairly complicated set of constructs and simplifies them dramatically.

Looking forward, DVR is set.

@Brice Richard:There was a fair amount of controversy about that "nobody understands" statement.  But it's true - Back in the early 1990s, Dave Cutler was able to understand how every part of the system worked, but that's simply not true any more.  I seriously doubt that there is ANY general purpose operating system in widespread use where a single person can understand how the entire system works.

There are people who know everything about how the filesystems and I/O subsystem work (and a lot about how memory management and the kernel scheduler works), but I seriously doubt they understand deeply how the display driver infrastructure works with the internals of GDI, User and DWM. 

It's simply to big for one person to comprehend.

This is why have extensive internal documentation about the interactions between the various subsystems.  Of course the quality and accuracy of that documentation varies from component to component but in general, it's good enough.  And of course there are area experts that are well known within the Windows team - you've met several of them here on C9 (Arun Kishan and Landy Wang come to mind immediately).

@Sean:There were also other changes - all the notification area icons got new graphics - they went from multicolored and vaguely 3d to monochrome and flat as well.

"In regards to managed.  I was not proposing streaming bit in .net.  More a bcl wrapper for config and metadata - start, stop, connect, status, change defaults, change endpoints, etc.  The lower level will still handle the streaming.  There has to be some managed story for this going forward. "

I don't know how you do start/stop without streaming - start/stop is intimately associated with streaming.  But there might be an opportunity for managed wrappers for some of the other parts of the audio infrastructure, who knows what might end up being developed in the future.

androidi: One critical thing to consider - Windows tends to be developed for the noob.  My quintessential example is my wife's riding instructor who is a stereotypical computer user.  She ends up calling us when the sound stops working when she tries playing back DVDs (it's an issue with the sound drivers but I can't explain that to her).

Whenever I think about sound features, I try to think about how this stuff would work for her.  Whatever we do has to be discoverable and usable for someone with little technical expertise.   It also needs to solve a particular customer scenario.

I like staceyw's scenario above for that reason - he's describes a clean scenario where he's trying to accomplish something that he can't implement using our current system without a great deal of difficulty AND his scenario is something that I could easily imagine customers encountering.  That scenario IS something that we might be able to address in a future version of Windows, Frank's already added it to the very long list of potential features (some of those potential features have been on the list for decades so there obviously are no guarantees about any particular feature being implemented).

Androidi: A large part of the reason for those cards being so expensive is that the market for them is so small.  Because the market is small, the price is high.  Creative has some decent MIDI devices for between $50 and $100 though.

It's possible that if more apps used MIDI there would be a bigger market for MIDI hardware but the reality is that for most applications PCM audio meets their needs.

Stacey, you're describing a system which would confound the vast majority of users adding a huge amount of complexity for unclear benefits.

Windows has always taken the attitude that application authors get to choose if they want to allow the user to specify a particular input or output device or if the application just wants to use the system defaults (of which there can only be one of course).  At a minimum, it radically simplifies the programming model that app developers need to consider.

w.r.t. managed code, there honestly isn't a way to implement isochronous rendering of either audio OR video in managed code given the current state of the CLR.  The basic problem is that the GC can come in at any time and freeze all the managed code in the application for 200+ MS at a time - this delay is troublesome for audio rendering and deadly for video rendering.

Ytterbium: None of this was cut from Vista.  Some of this functionality was implemented in hardware and the audio device manufacturers cut the functionality from their hardware at about the same time that Vista shipped, but the two events were unrelated.

You're describing a feature that we've discussed several times before (the ability to output to multiple devices simultaneously).  There are some serious technical challenges getting this to work in all scenarios (for instance if you're outputting to an AV receiver and headphones, the sound may be several milliseconds out of sync which sounds crappy) and as such it hasn't made the bar for features (there have always been higher priority features to implement).

In Win7 when you plug your headphones in, audio will be automatically redirected (assuming that the app hasn't explicitly said that it wants to render to your desktop speakers), and when you unplug them it will be automatically redirected to the desktop speakers.  We've done a lot to make sure that everything works smoothly but we've not yet implemented all the features we want.

Part of the reason that I use weasel words like "probably" and "maybe" is because these features DON'T work in all circumstances.  For instance the stream switching behavior intentionally only works if an app uses the default output device - that's because we're not going to override the choice of the application - if the application said that it wants to render to the speakers, we're not going to override the app's choice.

Wow.  I'd love to have the crappiest of those laptops.

Mine's a Toshiba A100 with 1G of RAM and a 60G hard disk.