Elliot H Omiya, Larry Osterman and Frank Yerrace: Inside Windows 7 - Audio Stack | Going Deep

exoteric
I : Next<I>

Larry is back - and Elliot too! Movie.Play();

Ytterbium

Glad to see that these features made it back in to the OS, I'm not sure why they got cut in Vista

ChrisStepaniuk

Elliot, Larry, and Frank, thanks for all the work you've done on Audio for Vista and 7, truly wicked! Also, thanks for explaining and demonstrating the audio sound wave at the end of the video, I learned something new today!

Cheers!

JoshRoss
A righteous infliction of retribution manifested by an appropriate agent.

That was fun. Awhile back on the E7 blog, there was a post about Improving Audio Glitch Resilience in Windows 7. I thought some of the telemetry data and testing methodology would surely be discussed. Good thing it wasn't or this would have been a two hour interview. The link is worth the read.

-Josh

Charles
Welcome Change

In reply to JoshRoss

#Aug 11th @ 9:09 PM

Telemetry data was used to improve almost everything Smiley

Thanks for opting in!
C

chuckej
Making Music Makes You Smarter

Sounds like a step forward - but as founder of a company that develops PC music software and integrates music systems for schools as our primary business, and has installed hundreds of PCs solely focused on their Audio/MIDI capabilities - mostly leveraging properties of Creative Labs Soundcards, I am continuously anxious about Microsoft's direction/support of MIDI and aspects of the Audio stack.

I know this is niche, but it's not THAT niche..there are thousands if not millions of people who will (or would like to) use their PC without extra hardware / software for music making. And if there PC won't do it, I'm afraid they'll find the other brand (yeah them) that already supports these features....

Here are the two simple requirements that Microsoft must consider to remain a functional competitor to other OS's sfor entry level music-making applications:

1. Multiclient USB Midi support in Compliant Driver: Running more than one program that makes use of MIDI IN or OUT will cause an alert/error condition to the effect of "Cannot find a MIDI driver on the system". There are solutions to this via Third party hardware/drivers - but more and more keyboards/instruments guitars featuring USB ports and "compliant" MIDI outputs will experience this error/condition and will only serve to diminish the Windows experience and create confusion.

2. Low Latency upgradeable GM sound source. GM wavetable synth may have been a great innovation at one time, but it is an unusable output for music making. The latency is unusable, and even though the sound quality poor, it's the latency that kills it. A solution with 20ms or less latency is the right choice. Being able to insert a soundfont would be strategic, and in one single move, regain the support of music education and entry level music production.

Are there any improvements in Windows 7 regarding MIDI/GM Wavetable synth?

Larry Osterman

In reply to Ytterbium

#Aug 11th @ 3:07 PM

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.

staceyw
Before C# there was darkness...

Hi Larry and Team. Thanks much. Your timing on this was amazing. Messing with Encoder the other day, I discovered we/I need more audio UX to help manage many devices and mixing in this era of media and live streaming. Playing with "Virtual Audio Cable", I figure that is about the best abstraction for a human I could think of.

Thinking some UX like below would make things very explicit and simple in a new Media Control panel:

1) We have two Mics and a Line-In connected to a mixer node. You can drag and drop the lines. You can double-click the mixer to change volume levels on the various inputs.

2) The mixer is streaming to the default speakers *and a Recorder node that is saving my Karoke session to disk as an MP3.

3) Also, I am recording the line-in seperatly on another Recorder node to a Wav.

4) Moreover, I am piping the recorder node input to a new Azure audio streaming service endpoint.

5) Other open apps that use sound could show up as nodes also with lines connected as configured by the app.

A matrix of other variations are possible.

Thinking about your audio feedback issue. I am wonding if that same technique would make for some kind of simple air collision avoidance system. As other traffic gets closer, your feedback (looped back to you by other traffic) increases and could trigger alarm. Maybe stuff already works on this.

I would also like to explore Charles idea of IObserable more. A managed api for this stuff is (I think) required. IObservable would make a good choice to get audio Notifications, etc. Linq queries is also interesting. User could hook Linq queries into the Mixer above and filter for certain levels and/or sounds and just capture the filtered data. Thinking things like voice recognition filters and key word filters, or tell me when Jumping Jake Flash is playing, etc. Having a managed stack to create and hookup all the objects above is also needed.

Is audio and video groups the same or different? Think they should be the same as all above would also apply to video streams.

Larry Osterman

In reply to staceyw

#Aug 12th @ 3:06 PM

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.