Way back when I was in college, I learned Lisp using a derivative of Lisp called MACLISP (named for MIT’s project MAC, not for anything that came from a fruity company in Cupertino). One of the coolest features that MACLISP offered was the (DWIM) command – basically if you had a typo when entering an s-list into MACLISP, you could type (DWIM) and the MACLISP interpreter would fix your code for you (and yeah, it usually got it somewhat wrong :)).
Stream Switching is a DWIM feature in the audio stack. If an application is rendering to a default audio device and the device is removed, the audio stream will automatically switch to the new device. The same happens if the default device changes for other reasons (if the user changes the default device for example) or if the sample rate on the device changes (this can happen with certain types of audio hardware allow external controls to change the sample rate for the device).
We were able to figure out how to implement the stream switching logic in a fashion that causes it to work without requiring changes from 3rd party applications, which is really cool because it allows us to enable new scenarios without breaking appcompat – as long as the application is rendering to a default endpoint, we’ll stream switch the application without the app being notified.
If an application is rendering to a specific endpoint, we’re not going to stream switch when the endpoint is removed – we don’t know the reasons for the application choosing that particular endpoint so we don’t attempt to second guess the applications intent (maybe the user has asked that their music player only play through the headphones and not through the speakers because playing through the speakers would disturb the baby).
We also don’t support stream switching if the application is using WASAPI (the low level audio rendering APIs) to render audio. That’s for a number of reasons, but mostly it’s because the presumption is that any application that is using WASAPI is using a low level rendering API and thus doesn’t want this kind of behavior.
The stream switching logic is really cool in action, especially if you’ve got a machine which supports dynamic jack detection – when you’re watching a DVD in windows media player and you plug in a pair of headphones, poof – the audio gets redirected to the headphones just like you’d expect it to.
So that's another thing Windows will do behind our backs, and sometimes get it really really wrong, as it often happens. I hope there's an option to disable it?
Alexandre: There's no way of disabling stream switching. And I don't see how it could get it "really wrong".
Sounds like a pretty neat feature to me!
Excellent! I loved the new Vista port detection stuff, but always hated the "oops, I have headphones plugged in, so stop windows media player, exit it, unplug, and try again."
Another thing to look forward to tomorrow when I grab it from MSDN!
This is definitely a good thing. Vista's new audio stack introduced a problem where you could cause a device switch just by unplugging headphones, presumably because Vista drivers expose the headphone jack as a separate endpoint when the XP drivers didn't. This exposed a new class of bugs where programs would hang or crash when headphones were inserted or pulled during audio playback. I ended up having to debug this, and it was fun to find out that DirectSound kept returning success on Restore() and DEVICELOST on anything else. This was a rare exception to the audio stack's usual It Just Works(tm) behavior, and I was surprised that it didn't seem to be covered in the stacks of Vista preparedness literature.
Some newer programs will attempt to reinit sound when this occurs, but it sounds like Windows 7 will let the older programs continue working smoothly, too.
Wow, almost nothing for nearly a year, then half a dozen posts in 5 days. I could get used to this!
yeah, i remember seeing a demo of this one in channel 9. very useful feature indeed and i'm sure going to use it.
still, i'd appreciate it if we could get some kind of ui to switch streams selectively, i.e. for specific apps only and from any stream to any other stream (rather than for all apps from the default stream but only when that stream change). oh well, i guess we'll see it win7sp1... ;)
I noticed this in the RC and it really is an awesome feature :)
However, the same thing doesn't really work for microphones as far as I can tell.
For example, Im playing a game, I want to plug in my headset the audio switches over to it fine, however the microphone will not work until I exit and restart the game.
Im unsure if this is just the app, or if input devices are not counted in "stream switching".
Does it work with Bluetooth headphones?
Alexandre: It should work on any headphones. It doesn't work with remote desktop endpoints though.
Robert: I don't believe we stream switch input devices. I'll ask the stream switching folks.
Thanks for the reply Larry, maybe for Windows 8 :)
Robert: Actually, stream switching capture devices has its own set of challenges - for instance the microphone volume is typically different on each device and mic tuning / agc is only done at the start of the stream. This makes switching automatically highly likely to cause a negative experience for customers. But maybe.
Now, any ideas why the Headphones/Line Out port on my Latitude D820's docking station doesn't work under Windows 7 RC? I have to use the one on the laptop itself. Not critical, but slightly annoying that it's something else to plug in or unplug when docking or undocking.
Given Dell's unbelievable slowness in getting working drivers just for Vista x64 - the video driver on their site for the nVidia Quadro NVS 110M chip is STILL the January 2007 version, known to be very buggy - I don't hold out hope for Windows 7 x64 drivers that actually work, and I'm a bit wary of trying Windows Vista drivers!
Mike - try going to nvidia's site; these days they offer laptop drivers. It works fine for my D620.
I'm a bit confused by the comment about audio being automatically redirected to headphones when they're inserted. Is this a new feature? Because this has worked for me for years, on various versions of Windows (even Windows Server 2003).
I get the idea of the stream switching, but don't know how it relates to headphones.