posted by Larry Osterman

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.

posted by Larry Osterman

posted by Larry Osterman

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

posted by Larry Osterman

posted by Larry Osterman

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

posted by Larry Osterman

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.

posted by Larry Osterman

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.

posted by Larry Osterman

posted by Larry Osterman

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.

posted by Larry Osterman

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

posted by Larry Osterman

Many applications (Skype, Live Messenger, WMP, etc) have UI which allows them to redirect their audio to any device, as does the Windows Sounds stuff.  Unfortuantely the Media Center team hasn't chosen to add this support to their application which prevents you from getting your scenario to work.

posted by Larry Osterman

posted by Larry Osterman

posted by Larry Osterman

posted by Larry Osterman