Microsoft Vista Audio Summit Report

[Garritan]

I'm in Seattle at the Microsoft Audio Summit. The Microsoft Digital Media division has organized a summit for the audio community to provide an in-depth review of the audio architecture in the next version of the Windows Operating System. This is very first audio summit Microsoft organized to focus on development in the audio world. Vista will have completely overhauled audio, from the low-level kernel guts to the user interface

Several days of workshops, demos, labs, networking and opportunity to talk directly with Microsoft Audio professionals. Lots of Q & A too throughout the sessions. There are about 80 audio professionals at the event from many of the major companies who were invited including Cakewalk, MakeMusic, Sibelius, Steinberg, Waves, SONY, Creative Labs, Line6, MOTU, Mackie, Propellerheads, Yamaha, Universal Audio and many other leading audio companies. Tom Hopkins and Jeff Hurchalla are here representing the Garritan team.

Last night there was a reception where we had a chance to grab a drink, meet and chat with some of the attendees. This morning Jim Allchin, Co-President of Microsoft Platform Products and Services, opened the Summit and with a Keynote session providing an overview of Vista. This was followed by a presentation of Vista audio by Pat Azzarello and Eric Schmidt. They talked about how Vista simplifies and improves audio over XP. Elliot Omiya then talked about User Mode Audiothe new audio system in Vista.

We enjoyed lunch with Steve Ball, Group Program Manager of Windows Audio. We discussed DRM, sampling and various other topics. After lunch there was a session on hardware initiatives followed by a session on Vista Development Tools and then a talk by Eric Schmidt about Partner Development.

It was nice to get a glimpse of the new Vista interface throughout the sessions. Since many work in the Window environment for long periods of time, it is nice to have a new spiffy user interface. Vista will offer some nice visual effects into the OS such as transparent windows, 3D rendering and animation that makes the work environment not only look cool but enhance functionality.

From the various sessions there are salient features I gleaned regarding audio in Vista:
Glitch-Resilient Audio - Vista provides better audio stability and manages audio in much more efficient ways. Audio app crashes and blue screens may be a thing of the past. The kernel of the Vista OS has been rewritten in order to prevent a software problem with drivers from bringing down the whole system.
Arif from Microsoft gave a demo comparing XP to Vista, stressing the CPU with maximum loads and trying to bring both to their knees. XP crashed early on but Vista kept going and going and going...and no glitching during the stress test. Very impressive.
Prioritization of Audio - The entire OS has a priority structure so that you can specify what apps get priority. You can prioritize audio to make sure any other program (like a virus program or AIM) doesn't get in the way and cause a glitch.
Per Application Volume Control - Vista has a new audio control panel that allows separate volume control per application. Did you ever get that sudden instant-messaging soundblast that's ten times louder than your other sounds? This won't happen in Vista and this feature is a welcome addition.
Improved Audio Performance -There are various other audio enhancements in Vista such as:
Better memory management & CPU performance
Support for up to 144 dB signal to noise ratio
Reduced latency
16bit integer to 32 floating point to improve audio fidelity.
And 64-bit version of Vista that will make 64-bit computing a reality under windows. This is only a very brief overview. There's lots more to get excited about with the next operating system from Microsoft. There were many technical aspects and under-the-hood features discussed. I'm glad Jeff came along to understand many of the finer technical infrastrstructure aspects of Vista audio.

Later tonight there is a swanky evening event at the Triple Door club. We'll be eating, gabbing, drinking and grooving to the music of a Seattle band called "Lushy". I'll try to avoid getting too 'lushy' tonight.

Tomorrow is another full day at the Summit. Also tomorrow evening will be the Northern Sounds/GPO Forum get-together at the Pike Place Brewery followed by our presentation at the Seattle Composer Alliance/Hummie Mann Film Scoring Program. Friday I'll be at the Microsoft campus at Redmond all day for some meetings.

Many thanks to Pat Azzarella, Eric Schnmidt, Steve Ball, Jim Allchin, Arik, Elliot and the rest of the Microsoft audio team for making this successful summit possible.

More later...;)

Gary Garritan

[Styxx]

Thank you Mr. Garritan! Vista sounds welcoming for us PC users. The features you outlined sound oh so promising. I was impressed with the stress test involving Visa and XP.
Looking forward to hearing more and have a great time.

[Stephanie Pray]

This is really exciting news :) Thanks Gary :)

[wst3ae]

Hi Gary,

Can you do a little digging and (hopefully) put a really nasty rumor to rest?

It has been reported that Vista will not allow users to install unsigned drivers. AND, getting drivers signed will have a price tag associated with it (the typical quoted cost is $500 per driver per year).

Now $500 is less than noise to a large video card manufacturer, and it is probably still noise to a large audio card manufacturer, but to a small operation that sells high-end audio cards this could be a real good reason to exit the market.

All of this on top of having to re-write one's drivers, which is annoyance enough.

So, can you see if there is any truth to this, and if MS is aware of the pain and suffering that they may be causing in a niche of a niche marketplace?

Thanks!

[Christopher Duncan]

Gary,

I don't know if he's going to be at this conference or not, but poke around with the MS guys and see if you can find Tom Archer. These days he's the MSDN Program Manager for Windows Vista (as well as Visual C++ & the Windows SDK) - http://msdn.microsoft.com/WindowsVista , so he might be there.

He owes me so many pizzas that we've lost count. Tell him I said to buy you one with extra pepperoni and I'll take it off his tab. ;)

Pizza aside, he's a great guy and a geek's geek - you'll have a good time talking to him, particularly if it involves programming.

[JonFairhurst]

Gary,

Thanks for sharing this. Each of the bullet points is really significant. I'll be an early adopter for sure!

-JF

[dewdman42]

Sounds exciting. Gary I don't know if you'll get this in time, but I am very curiuos to know whether they are moving midi handling deeper into the kernal as well. Windows has been notoriously mediocre for years in terms of midi timing. What it has needed for a long time is the ability to timestamp midi events and have the kernal send them exactly on schedule. Just wondering if they are fixing this in Vista also or if they are just focusing on Audio because of the $$$$ in games and other media playback situations...

Sure hope also that audio deeper in the kernal will not actually make midi playback worse than it is in XP. Its reasonably acceptable in XP.

[Houston Haynes]

There is no such thing as poor MIDI in Windows - only poorly written MIDI drivers.

The ability to prioritize processes will have an impact, as well as resolving the previous potential to have an application timing events by two different system clocks. Then again, a properly written app can already deal with that in XP, and has been that way for some time.

The question is: will the Windows Vista API prevent sloppy MIDI programming...

:samurai:

I'm really interested to hear more about the new protocols, and what they will do. Is there a site that we can go to for more information Gary?

[dewdman42]

I completely disagree with you Hous.. sorry. I've played around with programming to all the various windows midi API's including DirectMusic, etc.. and researched this issue heavily; and the midi timing is BARELY acceptable. This is a long understood issue amongst windows midi programmers and MS has not ever really fixed it except to make XP more solid and faster CPU's have hidden the issue. As a matter of fact, in the win95 days they were able to make more solid midi timing than now because they could thunk into a 16bit DLL and force the kernal to prioritize midi events. But that was lost in in Win2k and XP. Win2k flat out sucked, they made XP better..but there is a huge potential for them to get it wrong in Vista if they have dismissed midi as insignificant, particularly if they prioritize audio so high that midi falls back into unimportant land.

I would definitely like to know if this is being at least considered in Vista and not forgotten. I suspect they are focused on game audio, not audio production. As such, they will probably get the midi qeueing wrong, but that is just a guess.

[dewdman42]

Furthermore, I will add, that some audio apps, such as Cubase, actually tied the timing of midi to audio as way of trying to get the midi more accurate. This is one reason why Cubase has a long reputation of crappy midi timing and if you go into their forums and do a search you will find many people even still today experiencing midi timing problems...UNLESS they are making sure to have at least one audio track going on..at which point Cubase is able to force the midi to be more accurate and stable. Much of this is because of ASIO.

In any case, all I'm saying..is there is a huge potential for MS to completely miss the ball on MIDI. They did on win2k. Midi is not too important to them.

[newmewzikboy]

...

He owes me so many pizzas that we've lost count. Tell him I said to buy you one with extra pepperoni and I'll take it off his tab. ;)

Pizza aside, he's a great guy and a geek's geek - you'll have a good time talking to him, particularly if it involves programming.

YEAH?? I know his boss, and his boss owes me pizzas...and...and...so there too! pleeeze

[newmewzikboy]

dewd, gary...thanks for the great info

[Houston Haynes]

Furthermore, I will add, that some audio apps, such as Cubase, actually tied the timing of midi to audio as way of trying to get the midi more accurate. This is one reason why Cubase has a long reputation of crappy midi timing and if you go into their forums and do a search you will find many people even still today experiencing midi timing problems...UNLESS they are making sure to have at least one audio track going on..at which point Cubase is able to force the midi to be more accurate and stable. Much of this is because of ASIO.

In any case, all I'm saying..is there is a huge potential for MS to completely miss the ball on MIDI. They did on win2k. Midi is not too important to them.

Oh hey - don't let me get in the way of the imperical evidence you cherry pick from user support forums - I've only written MIDI drivers in C and assembler for the NeXT platform (running through the Moto 56000) - built the physical interface it used by hand under the guidance of Bob Moog - and understand asychonous data transfer in the Windows API and have studied both the ASIO and VST protocols - what do I know?

:rolleyes:

The fact remains that there are many, many device manufacturers who do *not* have to use any workaround to get accurate MIDI timing out of a Windows/ASIO system because the device is not cheaply made and the drivers are written correctly to begin with. If you care to scrutinize the details of who's posting complaints and where the root cause really lies, you will find that your example does not challenge my assertion, but rather reinforces it.

I'd expect that the API will be a bit more "boxed in" and some driver developers will not be allowed to trip over themselves quite so easily in developing MIDI drivers for Vista. That's one of the reasons why I was looking for more information on these protocols. I've seen other Vista API information at my day job, but would like to see more resources about developing media apps.

Gary - any pointers?

[dewdman42]

Easy does it there dude..no offense intended. Sheesh. I did not, by the way, "cherry pick" my information from internet forums, thank you very much. Don't be a jerk about it.

The main problem with windows is not the midi api per say, its the lack of a reliable multimedia timer. The one in windows can be interrupted by other things such as moving a window. There is not currently any way to prioritize it. Supposedly, DirectX has some midi routines that go deeper and somehow get priority....but not documented very well, and DirectMusic is an extremely cumbersome API that was really designed for a special purpose, and in fact is not even going to be fully supported anymore.

As I said quite clearly, some developers have found ways to make it work, usually piggy backing on the lower level driver such as ASIO. I don't want to debate with you about this, its outside the scope of this forum.

My question for Gary remains...about whether or not MS is making sure that a proper API for midi queuing is going to be improved in Vista in addition to Audio; and not forgotten. I am glad to hear they are building audio into the kernal to ensure it won't be pre-empted. Would sure be great to know if midi was also going lower into the kernal for exactly the same reason.

Apple made great improvements to their CoreAudio and CoreMidi API's in OSX..People have been hoping for MS to do something similar for a very long time for midi as well as audio.

[Houston Haynes]

OK - we agree on most points - thought that was a possibility. I guess I was thrown off by your "completely disagree" statement. ;)

One thing's for sure, DirectSound was a fiasco, and the WDM didn't help things much. One of the reasons why there's so much latency on feedback for things in the sound scheme for the OS is that nearly everything got a whack at the CPU before audio was pushed out in response to some action on the UI. And you're right that just because they have kernel-level audio prioritization, it doesn't mean automatically that they've put MIDI to the same priority.

For sure - it would be nice to know unequivocally - one way or the other. If it's possible to make MIDI sample-accurate inside of an application, it should be possible all the way to the output port - and it sure as hell isn't rocket science.

[dewdman42]

Definitely not rocket science. Its beyond me why it hasn't been done earlier, but I think its just more of an oversight. Audio has far reaching consequences for multi-media playback, gaming, etc... How many people are there out there using midi sequencers in the grand scheme of things? Not many. XACT even did away with midi altogether (XACT is MS's replacement for DirectMusic's toolset, designed for game audio).

So yes, cross our fingers and hope....

[Skysaw]

It has been reported that Vista will not allow users to install unsigned drivers. AND, getting drivers signed will have a price tag associated with it (the typical quoted cost is $500 per driver per year).
Before the thread goes off into a hedge maze, can we focus on the above issue for a moment? Anyone know anything further? I'd love for a new OS to care about audio, but not if it's just a giant marketing scheme to kill all other audio hardware and software suppliers.

[tradivoro]

Per Application Volume Control - Vista has a new audio control panel that allows separate volume control per application. Did you ever get that sudden instant-messaging soundblast that's ten times louder than your other sounds? This won't happen in Vista and this feature is a welcome addition.

The way to get around this without using vista is to take all those sounds in windows and minimize the sound level permanently in an audio editing program....

[Houston Haynes]

Before the thread goes off into a hedge maze, can we focus on the above issue for a moment? Anyone know anything further? I'd love for a new OS to care about audio, but not if it's just a giant marketing scheme to kill all other audio hardware and software suppliers.

I'm not sure if a technology summit is a place where that kind of stuff is going to be bandied about - but I'd imagine that the business side of things would have been settled long ago. There's gotta be a go-to resource for this, and I doubt it's the architects of the technical solution - with whom it seems they're spending most of their time.

I'm also a bit mystified as to how a few hundred bucks for signed driver validation is going to "kill all other audio hardware and software suppliers"... that seems to be a meritless jump.

Edit - found this (http://www.microsoft.com/whdc/system/platform/64bit/kmsigning.mspx), which is about writing kernel level drivers - and it does seem to 'box out' open source driver development to some degree - or at least will force them to get a Publisher Identity Certificate (PIC) from Microsoft. Microsoft won't charge for it, but they require that driver developers to have a Class 3 Commercial Software Publisher Certificate from Verisign. The Verisign cert is $500 per year.


What this means for Windows Vista.
To increase the safety and stability of the Microsoft Windows platform, beginning with Windows Vista:

• Users who are not administrators cannot install unsigned device drivers.

• Drivers must be signed for devices that stream protected content. This includes audio drivers that use Protected User Mode Audio (PUMA) and Protected Audio Path (PAP), and video device drivers that handle protected video path-output protection management (PVP-OPM) commands.

• Unsigned kernel-mode software will not load and will not run on x64-based systems.

Note: Even users with administrator privileges cannot load unsigned kernel-mode code on x64-based systems. This applies for any software module that loads in kernel mode, including device drivers, filter drivers, and kernel services.

• To optimize the performance of driver verification at boot time, boot-driver binaries must have an embedded Publisher Identity Certificate (PIC) in addition to the signed .cat file for the package.

What this means for software publishers.
For vendors who publish kernel-mode software, this policy has the following effects:

• For any kernel-mode component that is not already signed, publishers must obtain and use a PIC to sign all 64-bit kernel-mode software that will run on x64-based systems running Windows Vista. This includes kernel-mode services software.

• Publishers who provide 64-bit device driver or other kernel-mode software that is already signed through the Windows Logo Program or that has a Driver Reliability Signature do not need to take additional steps— except for the special case of boot-start drivers.

• Drivers for boot-start devices must include an embedded PIC. This requirement applies for these devices: CD-ROM, disk drivers, ATA/ATAPI controllers, mouse and other pointing devices, SCSI and RAID controllers, and system devices.

This information applies for the following operating systems:
Microsoft Windows Vista (for x64-based systems)
Microsoft Windows Server code name "Longhorn"

[Markleford]

I'm also a bit mystified as to how a few hundred bucks for signed driver validation is going to "kill all other audio hardware and software suppliers"... that seems to be a meritless jump.
There is a wealth of freeware drivers out there that are useful to a lot of people. While their developers could probably take up donations for reimbursement, it's forcing a previously "charitable" effort into the realm of commerce.

It's not just the hardware manufacturers who presumably have money to throw at a license that have to worry about it. Even virtual device drivers, such as MIDI-OX, Maple MIDI, and even GPO Studio itself which would have to "play ball or not at all"!

(And we all know that Verisign are more evil than Microsoft! ;) )

- m

[Houston Haynes]

(And we all know that Verisign are more evil than Microsoft! ;) )

Sounds to me like the OS dev community needs to campaign against Verisign - maybe they'll restructure their fees. Heh... like that's going to happen...

:rolleyes:

[Markleford]

Well yeah, especially when Verisign has their hooks so deep into ICANN (http://news.zdnet.co.uk/internet/0,39020369,39255204,00.htm).

Want to keep your .com registration? DON'T GET THEM MAD! :D

- m

[wst3ae]

I'm also a bit mystified as to how a few hundred bucks for signed driver validation is going to "kill all other audio hardware and software suppliers"... that seems to be a meritless jump.

It is not meritless... I have several friends who develop and/or sell drivers that are used by the music community. All of them are concerned at some level about this restriction.

The market for professional audio interfaces is small. I mean REALLY small. The market for pro-sumer interfaces is much larger, but in reality, it is still small.

For a developer with cards already in the marketplace there is a certain "requirement" to get the drivers certified, or get the Verisign cert, or whatever form the requirement finally takes, so that their customers can continue to use the hardrware.

And that doesn't take into account all the drivers that are provided with soft synths, and all the little tools that operate as drivers that make our lives easier. Many of these are either freeware or very inexpensive shareware.

From the 800 pound gorilla's point of view there is tremendous value in getting all of the drivers that might ever be installed into their operating environment tested. And that is not an inexpensive proposition.

But from the user's point of view it is much less valuable. If vendor A charges $500 for a professional quality interface then the customer has an expectation that the vendor has qualified the software that supports it. If that expectation is not met the vendor will shortly be doing desktop support again<G>!

There are already mechanisms in place to regulate this sort of thing. They seem to work pretty well for our little corner of the marketplace.

To you first comment, I don't know if the technical summit is really the place to ask the question either, but having attended my share of technical summits, they are, at best, equal parts technical and marketing, and it is possible that the topic will be broached.

Bill

[Houston Haynes]

Here's some more information for those that are interested in understanding more of the technical side of things.

http://blogs.msdn.com/larryosterman/archive/2005/09/23/473351.aspx

[Pat Azzarello]

Before the thread goes off into a hedge maze, can we focus on the above issue for a moment? Anyone know anything further? I'd love for a new OS to care about audio, but not if it's just a giant marketing scheme to kill all other audio hardware and software suppliers.
It's not a giant marketing scheme. There were critical changes and rewrites made to the OS this time around. These changes were made based on feedback from Pro Audio apps over the years. The Summit was about letting these folks know what was done. There were criticisms of some of the designs, and they were taken back and are being considered for correction.

Most of the OS changes require application changes as well, so you'll need to wait for updates to see the value, but some of the app writers have already committed to making some changes by the time Vista launches.

[Pat Azzarello]

Apple made great improvements to their CoreAudio and CoreMidi API's in OSX..People have been hoping for MS to do something similar for a very long time for midi as well as audio.
Apple did a great job here. On Windows, most of that same functionality is currently available with the applications (i.e., Sonar, Cubase, PT, etc.).

There are no new MIDI features in Vista, but three things to consider that may help MIDI in Vista:
1. Much of it has been rewritten to be more efficient.
2. The same features that allow audio to be glitch resilient could also be applied to MIDI threads, but that requires changes to the application. There's no way around that. I'll mention the MIDI concerns to our "Sequencer" partners as I talk to them over the next few months.
3. We're fixing MIDI bugs, concentrating on the ones that would most likely affect stability and performance.

It's too early to tell how much of an impact this will have. We also had a long discussion with about 50 people from the industry to see what they would want to see from the OS in terms of MIDI suppport. Tom White from the MIDI Manufacturer's Association was also there and Tom and I will be talking a lot about post-Vista improvements and changes. MIDI is a standard and we aren't going to do anything outside that standard, but we have someone on their technical board and we're involved with most, if not all, of these discussions. BTW - Timestamping is one of the things we'll look at.

Pat

[Houston Haynes]

There are architectural changes that will "trump" some of the concerns bandied about here. First of all - nearly all of the API has been moved up into user mode, so you don't have to write to kernal drivers for low-latency apps. This could be huge. Unless I've read things wrong, this means two important things: 1) that you don't have to have a PIC certification to write low-latency apps (if the end user can install as an administrator, they can put apps on that use unsigned user-mode drivers), and 2) that if there's an error in the audio portion of the system, you don't get a BSOD because the error conditions are not on the kernel level.

There is also a new device topology API, which means that apps are going to be able to directly access ports on devices instead of having to "imply" that the device port is there (i.e. the dreaded "emulated" port debacle) and getting into transformation and handling of data between user and kernal mode drivers that caused so many problems for people using cards with poorly written drivers (because the hardware driver fails to declare ports in a way that the app/system can directly address them). You may not see exactly what you're looking for with the first deploy of Vista, but they're getting the "primitives" right so that can make adjustments that will close the gap within the new core architecture (see their notes on the API being targeted to unmanaged C++ in the initial stage).

For a 45-minute exposition of the new audio engine in Vista, check this (http://channel9.msdn.com/ShowPost.aspx?PostID=146043) out.

[dewdman42]

It's too early to tell how much of an impact this will have. We also had a long discussion with about 50 people from the industry to see what they would want to see from the OS in terms of MIDI suppport. Tom White from the MIDI Manufacturer's Association was also there and Tom and I will be talking a lot about post-Vista improvements and changes. MIDI is a standard and we aren't going to do anything outside that standard, but we have someone on their technical board and we're involved with most, if not all, of these discussions. BTW - Timestamping is one of the things we'll look at.
Pat

That's very good to hear. That is exactly the answer to my question. Thanks. Is there anyplace online yet to read up about the changes in VISTA that application developers will need to re-write to take advantage of new efficiencies (I'm speaking only about midi now, not audio of which I'm sure there is already a lot of info and will continue to be more). ??

Anyway, the important thing is that midi is still being considered important and steps are being taken to improve if it not just make sure it continues to be at least as stable as it is now in XP.

[dewdman42]

For a 45-minute exposition of the new audio engine in Vista, check this (http://channel9.msdn.com/ShowPost.aspx?PostID=146043) out.

Interesting video. Thanks for sharing. I read through the follow up forum posts and Larry makes it pretty clear that very little has been done in Vista related to midi. Oh well..

It'll be interesting to see how this change in the audio engine effects ASIO and pro audio apps in the months to come. Can NOT complain about the fact that they are hopefully reducing the need for kernal level programming in application code in order to get low latency playback. I don't know how ASIO is implemented internally, but perhaps it will be simplified. I'm not confident it will be eliminated any time soon.

Its just too bad they didn't also add midi timestamped playback into that audio engine as well. If its still basically up to application developers to handle the timing of midi events, then it still comes down to the lousy timers in Windows which are easily pre-empted.

I think recording midi tracks is more of an issue about these timers being less than steller. Somebody has to generate the timestamps at that time. Playback is less of an issue, I suppose, since 99% of everybody are using virtual instruments these days anyway. So an app can presumably schedule audio playback in the audio engine and it will happen on time. A time stampable API (similar to CoreMidi) is really more of a developer convenience than anything in this regard. But the only real reason for needing it is because the various timers available in windows are not reliable enough so really in the case of midi, the playback of midi events needs to be pushed lower into the kernal than what has been done in the past. As opposed to audio which is going the other direction.

(sigh)

[Houston Haynes]

Interesting video. Thanks for sharing. I read through the follow up forum posts and Larry makes it pretty clear that very little has been done in Vista related to midi. Oh well..

It'll be interesting to see how this change in the audio engine effects ASIO and pro audio apps in the months to come. Can NOT complain about the fact that they are hopefully reducing the need for kernal level programming in application code in order to get low latency playback. I don't know how ASIO is implemented internally, but perhaps it will be simplified. I'm not confident it will be eliminated any time soon.

I agree - ASIO will be around as long as XP, and probably longer. I'm curious if the user-exclusive mode of WASAPI will have enough hand-holds for Steinberg to feel comfortable deprecating ASIO for Vista. I guess that's why they haven't mentioned any intention to develop an ASIO3 spec yet... I'd love to see them focus on really tightening up the VST spec instead.

[dewdman42]

I would imagine, if Steinberg did anything...they would not do away with ASIO at all. They might re-plumb it so that it is based on the Vista audio engine "service" instead of using their own kernal level code. I would hope they would at least TRY to do that much, if nothing else to make ASIO more happily coexistant with apps based 100% on MS api's.

Essentially, vista is changing things in such a way that application programmers can make things that do what ASIO does...without having to go into kernal mode to do it. It does make ASIO less of a neccessity, but so many apps are already entrenched in it.

It could simplify the implementation of ASIO, but I don't think it does away with ASIO since ASIO provides a lot of other higher level functionality, syncronization features, etc..and many apps are based, not only on that technology but also on the various API's related to ASIO.

If MS were to provide all of those higher level functions, based on Vista WASABI and the audio engine service, then perhaps ASIO would become obsolete unless Steinberg came out with something else revolutionary to trump what MS does. Frankly, I don't expect MS to provide all the capabiliites that ASIO provides. I expect that they will provide an improved low level API which people like Steinberg can choose to use for implementing ASIO or their app without having to do any kernal programming(or less).

Anyway, who knows...we're speculating now..... Just glad to hear about the new WASABI model, sounds like right thing, sad to hear that midi continues to be somewhat neglected.

[Garritan]

Here are some pictures from the Summit:


Tuesday night get-together at the WBar:

http://www.garritan.com/pictures/MS/MS-Wbar.jpg


Summit session on Wednesday Morning:

http://www.garritan.com/pictures/MS/MS-Session.jpg


Pat giving a Vista presentation:
http://www.garritan.com/pictures/MS/MS-PatAzz-talk.jpg


Microsoft kept us well fed and in good company!

http://www.garritan.com/pictures/MS/MS-lunch.jpg


Get-together Wednesday night at the Triple Door.
Pete Snell, Jeff Hurchallah and Pat:
http://www.garritan.com/pictures/MS/MS-PeteSnell.jpg


Thursday morning session:

http://www.garritan.com/pictures/MS/MS-hardware-session.jpg




http://www.garritan.com/pictures/MS/MS-Bldg50-steve-jeff.jpg

Jeff and Steve

Friday at the Port lab in Redmond:

http://www.garritan.com/pictures/MS/MS-portlab.jpg

[Garritan]

The Microsoft Audio (WAVE) Team:


Steve, Arif and Pat

http://www.garritan.com/pictures/MS/MS-Steve-Arif-Pat.jpg



At Steve's office
http://www.garritan.com/pictures/MS/MS-Steve-Gary.jpg



Arifm Noel at Mitch at the Redmond campus.
http://www.garritan.com/pictures/MS/MS-arif-noel-mitch.jpg



Eric and Larry Osterman

http://www.garritan.com/pictures/MS/MS-Eric-Larry.jpg

[Garritan]

*bump*..............