I just ran into this fairly old post on Channel 9. mstefan reported that his applications played a “Ding” noise when selecting an item in a listview (or tree) control.

It turns out that I’d had the problem independently reported to me by one of the people here at Microsoft. Here were his reproduction steps:

Clean Install Windows

Open the sounds control panel

Set the “Select” sound to a value

Clear the “Select” sound (set it to “(None)”).

Change the selection in a listview

Complicating matters is that this didn’t occur with many apps, just a couple of Windows Forms applications that the person at Microsoft had. So I dug into it a bit.

I quickly realized that the problem was that the application was calling PlaySound without the “SND_NODEFAULT” flag. I’ve written about this flag before (in fact I wrote that post shortly after investigating this issue, so that post contains part of the story).

Digging in deeper, I realized that the application was using version 5 of the common controls (there are two versions in Windows, v5 and v6). The problem didn’t occur in the version 6 common controls (this is why most applications didn’t reproduce the problem).

So why did the problem occur?

The common controls have a single routine which calls PlaySound and that code attempts to be somewhat clever. Instead of simply calling PlaySound, the code instead read the HKEY_CURRENT_USER\AppEvents\Schemes\.Default\CCSelect registry key. If the key didn’t exist, it skipped calling PlaySound. If the CCSelect registry key existed, it would call PlaySound specifying the CCSelect alias.

I’ve actually run into this pattern a bunch in WIndows – teams decided that calling PlaySound was “too slow”, or had “too much overhead” so they tried to avoid the call to PlaySound if the call to PlaySound wasn’t going to do anything (once upon a time it was important to avoid calling PlaySound because it could sometimes hang your application for several seconds – this isn’t the case any more if you specify SND_ASYNC).

The problem is that when you hit step 2 above (setting the “Select” sound), the control panel created the CCSelect registry key with a default value of the sound file you’re setting. When you set it to “None” the control panel cleared the value of the sound contained under the key. But the key itself wasn’t deleted. So the check above that checked for the registry key’s existence succeeded and it called PlaySound. But because the call didn’t specify SND_NODEFAULT, the PlaySound API decided to play the default sound when it realized that there wasn’t a sound associated with the CCSelect alias.

I wanted to understand how this bug was introduced so I looked back at the source history of the file containing the bug. It turns out that this was actually a bug fix made to Windows XP that wasn’t incorporated into Windows Server 2003. When Windows Vista was created, the team started with the Windows Server 2003 code base and incorporated all the bug fixes made since Windows XP forked into the Win2K3 code base. For whatever reason, this particular fix was missed when the team did the merge. Because the behavior was so subtle (to trigger the change you MUST go through steps 2 through 4 to get the registry key created and your app must use the v5 of the common controls).

I’ve always believed that the most frequently used multimedia API in winmm.dll was the PlaySound API. However I recently was working with the results of some static analysis tools that were run on the Windows 7 codebase and I realized that in fact the most commonly used multimedia API (in terms of code breadth) was actually the timeGetTime API. In fact almost all the multimedia APIs use timeGetTime which was somewhat surprising to me at the time.

The MSDN article for timeGetTime says that timeGetTime “retrieves the system time, in milliseconds. The system time is the time elapsed since the system started.”.

But that’s almost exactly what the GetTickCount API returns “the number of milliseconds that have elapsed since the system was started, up to 49.7 days.” (obviously timeGetTime has the same 49.7 day limit since both APIs return 32bit counts of milliseconds).

So why are all these multimedia APIs using timeGetTime and not GetTickCount since the two APIs apparently return the same value? I wasn’t sure so I dug in a bit deeper.

If you run this program, you’ll notice that the difference between the timeGetTime results is MUCH more stable than the difference between the GetTickCount results (note that the program sleeps for 53ms which usually doesn’t match the native system timer resolution):

That’s because GetTickCount is incremented by the clock tick frequency on every clock tick and as such the delta values waver around the actual time (note that the deltas average to 55ms so on average getTickCount returns an accurate result but not with spot measurements) but timeGetTime’s delta is highly predictable.

It turns out that for isochronous applications (those that depend on clear timing) it is often important to be able to retrieve the current time in a fashion that doesn’t vary, that’s why those applications use timeGetTime to achieve their desired results.

As I was writing my “25 years of Larry’s history at Microsoft in 1 year chunks” blog posts, I spent a fair amount of time digging through my email archives (trying to figure out exactly what happened at what time). During this, I ran into a link to a post I’d made on the Info-IBMPC mailing list mailing list back in 1992:

|| I recently acquired Windows 3.0 and I don't seem to understand one || thing. What is it for? What do I do with it? What major advantage || does it have over Dos? (I don't see any except being able to use mouse || and also the thing is bit more colorful) I think it was made for lazy || people who couldn't learn couple of DOS commands.

|| Don't tell me I could multi-task with it. I've been using Amigas || extensively

I've got to jump in here, even though I suspect that there will probably be some form of an "official" response from MS if anyone in the DOS/Windows group is listening...... :)

I'm going to be brutally honest about this one. Basically, Windows by itself IS pretty useless. The thing that makes Windows great is the same thing that has made DOS the most popular operating system in history. It's the applications that are available for it.

GUI's (Graphical User Interfaces) have been proven to be significantly easier for users to understand for beginning users, and are arguably the wave of the future. I don't know of a significant operating system being introduced for the PC market that doesn't have a GUI available on it, be it PM, X, GEM, or Windows. Windows is arguably the best GUI available for DOS based on what I consider the most significant criteria: What applications are available for the platform.

Consider the list of available windows apps: Excel, WinWord, PageMaker, Corel Draw, WordPerfect, Lotus 123, etc just to name a couple off the top of my head.

You also hit on one of the significant reasons to use Windows - Multi-tasking.

Windows is a non pre-emptive multi-tasking operating system. On a 386, it does an ok job of multi-tasking multiple DOS applications, but on a 286 it functions as a simple task switcher like DOS 5 does. It really shines when multi-tasking Windows applications however.

In addition, when you couple the multi-tasking capabilities of Windows with a windows mechanism known as DDE (for Dynamic Data Exchange), you can generate some truly incredible synergy between Windows applications. With Win 3.0/Win 3.1 Microsoft has introduced a concept known as OLE (Open Linking and Embedding) which allows you to cut and past from multiple "applets" allowing applications to take advantage of the capabilities of other shipped applications. This allows an applet like an equation editor to manage all the information about formatting an equation even when the equation is embedded in a word document. With OLE, you can simply double-click on the object and bring up the "agent" that manages it (in my example, the equation editor).

For application developers, Windows gives developers the ability to develop their applications without knowing anything about the underlying hardware of the machine - a windows application that runs on a machine with a CGA adapter will also run on a machine with a graphics accelerator that runs in 1024x1024 with 24 bits of color.

In addition, when you write an application for windows, your application instantly will support literally hundreds of printers transparently - Windows does all the work for you.

To re-iterate, Windows as a stand-alone product is not extraordinarily interesting - there are lots of productivity packages that provide similar functionality to users, the real benefit of Windows is the applications that run on it.

I will also point out that there are more than 5000 Windows applications available today and still more will come out with Win 3.1. The available windows applications span all ranges of applications from games (Microsoft's Entertainment pack, Berkley-Soft's After Dark, and Sierra's Laffer Utilities for Windows) to Spreadsheets (Microsoft Excel, Lotus 1-2-3) to Word processors (Microsoft Word For Windows, Lotus Ami), to Desktop publishing (Aldus Pagemaker, Microsoft Publisher), to presentation graphics (Microsoft Powerpoint), to development tools (Microsoft Visual Basic) etc......

Larry Osterman

Disclaimer: The opinions above are my own. They are not necessarily the same as those of Microsoft. I only work here.

Remember that this was written back in 1992 after Windows 3.0 had come out but before Windows 3.1. There was no Win32, no web browser, no multimedia support, none of the things that we all take for granted in a modern system. Back then a display card that supported 1Kx1K with 24bit color was considered a monster display card (and hard disks still came in “megabytes” – I remember buying a 2G hard disk back then for about a thousand dollars).

Reading this again, I find it vaguely funny that in many ways my feelings about Windows haven’t really changed that much in 18 years – the value of the Windows platform is STILL the applications available for that platform (although the number of applications has grown from the 5000 or so back in 1992 to several million applications).

I got up in the morning from temporary housing and put on my 3 piece business suit to start my first day of work at a relatively small computer company near Seattle called “Micro-Soft” or something like that. Within a day I’d been ridiculed for my choice of dress (“You’re wearing a ne-ne-ne-ne-necktie?”) and had to sign a dozen or more forms, been handed an employee directory and shown to my new window office – a converted conference room, but still a window office. I shared the office with Joe King (yeah, that was his real name) for about 2 weeks until I got my own office.

I’ve spent the past 25 days giving a year-by-year recap of my career at Microsoft, today’s been a bit of a whirlwind. I was originally going to recap the highlights of the past 25 years but instead I think I’ll just write about some of the events of the day.

My group had a lunch where we celebrated with a “Windows Mixer” cake decorated by Steve Ball:

I received my 25 year service award – the thing weighs about 30 pounds (it comes in a footlocker!).

And if you’ve seen the sound team, you know that we almost always have a video that goes with every event…

EHO and Kristin Carr, two of my co-workers wearing their “Larry Look-Alike Kits”:

My boss, Noel Cross with his Larry Look-Alike Kit:

I also was fortunate to have several of my co-workers from years gone by come by and share in the celebration, it was amazing seeing them again after several years.

Today’s been an awesome day, and I’m really looking forward the next 25 years!

Way back in 1985 I was busy working on MS-DOS 4.0. MS-DOS 4.0 was a multitasking derivative of MS-DOS 2.0 (during 1985 we integrated the changes for MS-DOS 3.1 to MS-DOS 4.1).

It’s important to remember the difference between MS-DOS and PC-DOS. PC-DOS was an IBM OS offering which was largely written by Microsoft. MS-DOS was Microsoft OEM version of PC-DOS (sold to companies like Compaq and DEC). The MS-DOS releases always lagged behind the PC-DOS releases.

Back in the mid 1980s IBM called the shots in the development of DOS – DOS releases were directly tied to IBM hardware offerings because IBM wanted a new version of PC-DOS for each new piece of hardware they shipped. For example, when IBM shipped the PC/XT, they added a hard disk (with a whopping 10M storage capacity) and they asked Microsoft to add support for hard disks. The MS-DOS team decided that the best way to support a hard disk wasto add a *nix style hierarchical filesystem with PC-DOS 2.0. When IBM created the PC/AT, they also delivered PC-DOS 3.1 which added support for the IBM PC Lan Adapter, a broadband networking adapter that IBM shipped at the same time as the PC/AT. It’s also important to remember that MS-DOS wasn’t a complete PC OS experience. Instead Microsoft provided the core OS and the command interpreter and a couple of utilities. Other utilities (like mode.com) were provided by the OEM. This changed with MS-DOS 3.2 which included a full set of the utilities that were provided by IBM. For MS-DOS 3.3, we were working with IBM under the Joint Development Agreement and as such we were finally able to ship the actual binaries that shipped with PC-DOS thus making MS-DOS identical to PC-DOS in functionality – but that didn’t happen until 1987.

MS-DOS 4.0 was unique because it was developed “on spec” – IBM didn’t see a need for a multitasking version MS-DOS and didn’t have a new hardware offering on which to attach the product. But IBM did have the PC/AT which was an 80286 based processor and it didn’t have an OS that took advantage of that hardware. So IBM and Microsoft started negotiations to take the MS-DOS 4.0 code base and turn it into what eventually turned into OS/2. I ended up not working on the OS/2 effort, instead I worked on finishing up MS-DOS 4.0 for the OEM partners who had licensed MS-DOS 4.0.

For MS-DOS 4.0 I worked on the BIOS (IO.SYS or IBMBIO.COM on PC-DOS). In MS-DOS terms the BIOS was basically the binary which contained all the built-in drivers – keyboard, screen, printer, serial port.

Edit: Removed extra "Z" introduced because I wrote this with my laptop balanced on my knee and the "Z" kept creeping in especially when typing IZBM.

Over the summer of 1985, Valorie came out to visit me for an extended summer – she worked as a tester on the Windows and Word team testing printer drivers until she left in December. And in December I proposed to her and she accepted my proposal, we got married in January 1987 (cue violins at this point :)).

23 years ago, I was working on finishing MS-DOS 4.0 and transitioning to work on MS-DOS 4.1. We also moved from the original Northup campus to the brand new 4 building campus herein Redmond. At the time the company mandated that we give up our President’s Day holiday and instead replace it with the day we moved to the new campus. Needless to say this did not go over well. I still remember one of my co-workers sending an email comparing John Shirley (president at the time) with Pope Gregory.

For me this didn’t matter because a co-worker and I ended up spending the move time in France working with Goupil to finalize a number of bugs that they had with MS-DOS 4.0 (for instance MS-DOS 4.0’s floppy driver didn’t work correctly on machines with more than 2 floppy drives (we weren’t able to test this because none of the machines we had access to had 4 floppy drives, but Goupil had a machine with 4 drives on it – if I remember correctly the issue was a confusion as to how the drive select bits on the uPD765 worked).

Ok, at this point it should be blindingly obvious where this series is going :).

In early 1987 I was still working on MS-DOS 4.1, a custom version of DOS for ICL in the UK. I also got married to my wonderful wife Valorie in January. We returned from our honeymoon and I wandered into work after getting off the plane (I’d parked my car at work and took the shuttle to the airport from work). That was a HUGE mistake because I learned that the entire MS-DOS 4.1 team was going on a plane to the UK in 36 hours. These days, I’d never do what I did next: I left my bride of a week at home (with a car with a manual transmission that she didn’t really know how to drive) for a week while I flew to the UK and met with customers (these days, I’d have insisted that Valorie come with me to the UK so we’d at least be together in the evenings and weekend). I spent a huge amount of time in the UK that year finishing up MS-DOS 4.1.

Between 1988 and 1990 I spent most of the time working on the Lan Manager family of products, starting with Lan Manager 1.1 and continuing through Lan Manager 2.0 (I left the Lan Manager team for NT OS/2 after Lan Manager 2.1).

LanMan was a hoot – LanMan was when I first started working with Brian Valentine (and later for Brian Valentine). Brian was maybe the most inspirational manager I’ve ever worked for, working for him was always a blast. This was also where Danny Glasser gave me the nickname “DOS Vader” – at one point in the very late 1980s, I probably knew as much about the internals of MS-DOS than any other developer in the world.

In Lan Manager, I was the developer for the DOS version of the Lan Manager client. It’s also when I had the “8 F**ING BASICS” meeting with Bill Gates. I started with a version of the messenger service for MS-DOS and then moved onto the network client – eventually I’d added support for a fully asynchronous programming model running under MS-DOS which was pretty cool (there were some limitations but in general it worked great).

In 1990 I joined the WIndows NT OS/2 team after working on Lan Manager for several years. I was one of about 4-5 developers who moved from the Lan Manager team to join the much storied NT OS/2 developers. I still have my copy of the NT OS/2 workbook in my office – it’s a collection of the specs that make up Windows NT (astonishingly many of the aspects of the workbook are still valid even after almost 20 years). In my office, I have a copy of the “NT Plan” which was the original schedule for NT. Some of the entries on the “NT OS/2 Issues” page were:

“Install operating system – who will write?” [Back then, setup was an afterthought]

Programming editor – what editor will we have? Need better than a simple system editor (Better than VI!) [They ended up with “M”, the “Microsoft Editor” which was a derivative of the “Z” editor].

1024 byte sectors for system files. Needed? Needed for Japanese floppies? How needed [floppy support was critical back in the 1990s]

The original schedule for NT OS/2 was that it would be demoed at Comdex in November showing off 4 “exciting 32 bit OS/2 applications” with no network filesystem support. The plan was for an SDK release in the 4th quarter of 1990. I also have the initial NT schedule for 1991-1993 which indicates that the plan was for 5 separate releases staged from 1991 to 1993, it ended up that none of the individual releases were made but the 5th release pretty closely aligns with the final Windows NT 3.1 project (which is pretty cool given how much changed in the NT project over that time).

In all honesty, I was in over my head on the NT project – I was trying to build a component that was intended for use in a multithreaded/multiprocessing environment having never previously written code for such an environment – before that all my programming had been in assembly on MS-DOS. I learned a staggering amount during my 4 years on the NT team and while it was extraordinarily painful, I came out of the experience a far better developer.

I was working on the NT team working on the NT browser. I was also preparing for my first major vacation in about 8 years – I was going to take 6 weeks off to visit Worldcon in Orlando, spend some time at Disneyworld, and visit my family on the east coast to show off the new baby. This wasn’t going to be a problem because Windows NT’s beta was scheduled to ship in July and we weren’t planning on leaving until Labor Day, I figured that 2 months would be sufficient padding. Unfortunately events conspired against me.

Early in the summer, the Windows for Workgroups 3.1 team unveiled a new architecture for the computer browser service that was a fully distributed client/server architecture (designed mostly by Henry Sanders, long before he was made a distinguished engineer). Not surprisingly the NT browser wasn’t compatible with this new architecture so I spent the summer scrambling to rewrite the NT browser to be compatible with the WfW browser. By the end of the summer, I thought I'd gotten all the kinks out of the browser and was ready to go on vacation. Unfortunately the beta had slipped by that point and it was scheduled for late October – about a week after I was scheduled to return from Vacation.

My boss was worried about the fact that I was checking in a major change a week or so before i went on vacation (there was a long tradition on the NT team of developers doing this) and that I wouldn’t have time to react to any issues that came up when I was gone so he insisted that I take a laptop with me (this was 1992, the laptops available then were remarkably bulky compared to the machines of the day). I dialed into the Microsoft remote access servers from Florida every day on my “vacation” to check on how things were going. The lightning storms that were happening daily wreaked havoc with the 9600 baud connection on the machine. Not much of a vacation really since I had to continually keep thinking about work.

About a week or so into the vacation, it became clear that things were not going well in browser-land - the WfW browser developers had rolled out a brand new version of the browser protocol which was incompatible with the old version and it was critical that the NT browser interoperate with the WfW browser (the WfW 3.1 team was going to ship before our beta release). So he asked me to come back to Seattle in the middle of my vacation.

Because the product was in crisis, I flew back to Seattle for a week in the middle of my six week vacation and worked 18+ hour days non-stop all week to adopt the browser to the new protocol. I finally was finished and checked in my code and again went back on vacation.

There were still a bunch of bugs that needed to be ironed out that were discovered while I was gone, and I’d missed a couple of important issues that had to be fixed during the remaining 2 weeks of my vacation, but for the most part the browser worked ok for the beta – it was far from high quality in the beta but it at least worked, so the return from my vacation was “worth it” (for some value of “worth it”).

The good news is that Microsoft’s culture has changed sufficiently since then that I don’t think it’s possible for any such event to occur. And more importantly, I don’t think I’d ever let myself be put in that position. Having to return from the vacation essentially took a relaxing vacation and turned it into a mild nightmare.

Oh, and if it wasn’t obvious from the above story, my son Daniel was born in January of 1992 :).

Sixteen years ago, we were busy finishing up Windows NT 3.1. On NT, I worked on the browser (network neighborhood) and the CIFS network filesystem, they both had their own challenges.

The NT browser (the computer browser service and bowser.sys (yes the name is NOT a typo)) were my first (and so far only) attempt at building a true peer-to-peer replicated system. It was surprisingly hard and I learned a great deal about how to build distributed systems while working on it.

Sorry, I was off on Friday so no post. 1994 was probably the most tumultuous year of my career at Microsoft. In 1994, I left the NT team to join the “Tiger” team, a research project dedicated to building a media delivery infrastructure (in 1994, this was extremely ambitious since the MPEG standards had just recently been standardized and there was very little hardware out there that could handle the loads associated with rendering streams of compressed video data). Unfortunately I really was unable to fit into the research development model so I ended up leaving the team after about 8 months to join the Exchange team. In the Exchange team, I started working on the “Push Notification” feature for Exchange 4.0 (yes, “push” was a big deal even back in the mid 1990s) and working on backup and restore capabilities. After Exchange 4.0, I worked on the POP3 server for Exchange 5.0 and the IMAP server for Exchange 5.5. I had a HUGE amount of fun during those years, I spent a great deal of time working with the various IETF email task forces and met a whole bunch of insanely cool people.

Eleven years ago, I was in the Exchange group, working on Exchange 2000 (same as 10 years ago :)). The summer of 1999 was when Microsoft rolled out it’s “Comp2000” system which completely reworked the compensation system at Microsoft. One of the drastic changes associated with Comp2000 was a radical rethinking of how employees were ranked. Previous to this, as a developer, your level was numbered from 10 to 15, with most new hires being brought in at level 10. After this change, the levels for individual developers ran from 59 to 80. There was a fair amount of discussion about “level inflation” going on at the time :).

In 1999, I was busy working on shipping Exchange 2000. Most of the work I did on E2K was related to re-engineering the security subsystem for Exchange – the original security subsystem used a custom ACL model, for Exchange 2000, I converted that to use NT style ACLs. This might have been the hardest technical challenge I’ve faced at work since it involved resolving two relatively incompatible ACL systems.

We also had some seriously epic parties in Exchange – I remember one from around 1999 which involved hot tubs on the patio between the buildings and a torrential downpour – maybe the best ship party ever.

The biggest event on my plate in August was that I took taken delivery of a brand spanking new Itanium machine that was intended for 64bit Exchange development :). We also shipped Exchange 2000 during mid 2000. 2000 was a time of some turmoil for the Exchange store development team – after shipping Exchange 2000, much of the store team left Exchange and moved to SQL server (where several of them still remain). I chose not to remain with the rest of the store team and instead moved onto the SCP team (I wrote about that team yesterday).

Between 2001 and 2002, I was working on the SCP project – SCP was a networking protocol that was designed for an embedded controller that was intended to be used for home automation. It was a power line carrier based protocol and was designed for an ultra low bandwidth (1 bit per millisecond) link. The SCP was designed by Harry Pyle and Rich Hasha who had worked on the home automation systems that were used in Bill Gates house. The final SCP chip was bout 10cm on a side, and contained 64K of hard metal ROM, 64K of RAM an embedded ARM CPU and a ton of custom circuitry developed by ITRAN Communications. For the SCP project, I was working on building a bridge between SCP controlled devices.

After the SCP project end-of-lifed in 2002, Dennis Flannigan who was the dev manager of the WMDG group at Microsoft (Windows Media and Devices Group) asked me to use my experience with SCP on a project to surface UPnP devices as PnP devices working under Frank Yerrace. I built a prototype for the idea and hit a dead end. Frank then asked me if I’d be interested in helping out on the sound team and I said “sure”. I’ve since had 3 different managers on the sound team, but it’s been over 6 years at this point.

2001 was a particularly bad year for me, I had a fairly serious back injury that put me out of work for 6 weeks and continued for another 6 months beyond that. My back’s been healthy since that, but it was NOT a fun 6 months.

As I mentioned yesterday, the Windows SDK is now live. For the Windows SDK, there are 9 new samples (and one changed samples).

Two of the SDK samples demonstrate the WIndows 7 “Ducking” feature – they’re actually based on the code I wrote for my PDC talk last year, but tweaked to show some new scenarios and clean up the code (the original PDC code was not ready for prime time, it was strictly demo-ware).

The DuckingMediaPlayer application shows both a really simple DirectShow based media player but also shows how to integrate the players volume control with the Windows per-application volume mixer. So if you’re wondering how to integrate the volume control for your application with the built-in per-application volume controls, this sample will show you how to do it.

The DuckingCaptureSample application is a trivial application that uses the wave APIs to capture audio data (and throw it away). This shows how to trigger the “ducking” feature in WIndows 7.

The other 7 samples reproduce functionality in the old WinAudio SDK sample – instead of providing a single monolithic audio sample, we crafted different samples each of which shows one aspect of audio rendering. All of these samples are simple console applications which read their parameters from the command line. They’re intentionally extremely simple to reduce the potential for confusion in the samples.

The EndpointVolume sample shows how to use the IAudioEndpointVolume APIs. It demonstrates using the VolumeStepUp, VolumeStepDown, SetMute and SetMasterVolumeLevelScalar APIs.

The CaptureSharedEventDriven sample shows how to use WASAPI in “event driven” mode to capture data in shared mode from the microphone.

The CaptureSharedTimerDriven sample shows how to use WASAPI in “timer driven” mode to capture data in shared mode from the microphone.

The RenderSharedEventDriven sample shows how to use WASAPI in “event driven” mode to play a simple sine wave in shared mode from the speakers.

The RenderSharedTimerDriven sample shows how to use WASAPI in “timer driven” mode to play a simple sine wave in shared mode from the speakers.

The RenderExclusiveEventDriven sample shows how to use WASAPI in “event driven” mode to play a simple sine wave in exclusive mode from the speakers. This also shows the “exclusive mode swizzle” that is required to align the buffer size with the hardware buffer size (which is required to work with many HDAudio solutions).

The RenderExclusiveTimerDriven sample shows how to use WASAPI in “timer driven” mode to play a simple sine wave in exclusive mode from the speakers. This also shows the “exclusive mode swizzle” that is required to align the buffer size with the hardware buffer size (which is required to work with many HDAudio solutions).

The reason we don’t have capture exclusive samples is that we felt that users of the SDK could derive the exclusive capture samples from the render samples if it was important to them.

All the shared mode samples also show how to implement stream switching.

One of the things I’m quite proud about the samples is their structure. Each sample has the following basic file layout:

WASAPIRenderer.cpp/WASAPIRenderer.h (WASAPICapture for capture samples): The code which does all the WASAPI rendering and/or capturing

<SampleName>: Scaffolding for the sample – this defines the command line parameters and instantiates the actual render/capture object and asks it to do the rendering/capturing.

Each of these samples is essentially identical, in fact they’re sufficiently similar that you can use your favorite file comparison tool to see what code has to change to go from one mode to another. So to see what changes are required to go from exclusive timer driven to exclusive event driven, you can windiff the RenderExclusiveEventDriven\WASAPIRenderer.cpp and RenderExclusiveTimerDriven\WASAPIRenderer.cpp files and see what changes are required to implement the different model.

We were busy in the “Longhorn Reset” where we essentially threw away the work we’d previously done for Longhorn and restarted based on a Server 2003 based codebase. We took the work we’d done for the Longhorn audio engine and reworked it to create the current audio engine we delivered with WIndows Vista – many of the concepts of the original engine remain (although several of them are gone and some of the functionality was radically reworked (for example in the LH alpha codebase, the waveOutXxx APIs used the MediaFoundation APIs to render audio – in Vista they use WASAPI directly). Things were pretty hectic, but none of the developers working on Longhorn were really sorry to see the old project go – it truly had become unmaintainable.

Also in 2004, I started this blog – back then it was hosted on another site, but my blog officially went live on March 15, 2004.

I just received email that the new Windows 7 SDK is now live! Apparently it’s not on the Windows SDK download site yet, but if you click on the first link, you can download an ISO which contains the SDK.

For the Win7 SDK, I wrote about 8 new samples in the Multimedia\Audio category, they’re described here (check the Multimedia\Audio samples. These samples replace the old WinAudio SDK sample – basically I took the old WinAudio sample and blew it up into 8 different samples which demonstrate different aspects of rendering audio using WASAPI.

I’ll write some more about the samples tomorrow – there are some cool things in the way the samples are structured that I hope will help developers who want to understand the difference between the various WASAPI render and capture modes.

I had just finished the Beta3 coding for Windows Vista. During that time I finished the per-app volume feature work and spent a bunch of time helping other groups finish up their initial coding. Things were crazy busy, especially during the final weeks as all the features landed.

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.

Back in the summer of 2006, we were all busy trying to finish Windows Vista. I actually spent most of July and August writing protocol documentation for old protocols that I’d written many years ago – I’m the principal author of the MS-BRWS document (it’s currently owned by the network team) and the MS-RAP protocol. The MS-RAP protocol was particularly complicated because of the declarative nature of protocol documentation specifications – the original LAN Manager remote admin protocol specification was based on string descriptor values which were parsed to determine how the data sent from the client was marshaled, but for MS-RAP there really was no easy way of expressing this (because the protocol specifications needed to be declarative not descriptive). Most of the MS-RAP is deprecated with WIndows 7, which is a great relief to me (that particular protocol existed to enable interop with LAN Manager administrative tools and I doubt very much that any of them are still in use today).

We had just returned from a 10 day cruise from Istanbul to Venice with most of my extended family (Valorie, the kids, my step-mom, my youngest brother and sisters and my kids “honorary grandparents”) – it was a huge amount of fun and we really enjoyed it – I don’t take vacations very often and this one was just wonderful (if only because I was off the web for almost 2 weeks).

The capture monitor is a feature that allows you to listen to a portable media player (or any other microphone input) through your PC speakers.

First a bit of history. Way back in the dark ages (Windows XP timeframe), audio solution manufacturers used to include an analog circuitry that connected the line in to the speaker jack on the PC. They routed this through an analog volume control and exposed this through the audio device topology. People used this functionality to connect their portable media players to their PCs. While this feature was popular with customers, the cost of providing the circuitry was too much for some IHVs and they started removing this functionality from their products starting some time before Vista shipped.

Not surprisingly, customers complained about this and we decided to implement equivalent functionality in the audio subsystem in Windows. Because we’re doing this in the audio subsystem instead of in hardware, it allows you to configure the capture to run between any two devices.

To configure the capture monitor, you go to the properties page for the input device and select the “Listen” tab:

Once you select the “Listen to this device” checkbox (and hit apply), the system will start capturing data from the input and rendering it to the output device. I’ve been using it to listen to my media player for months :).

I’ve been really gratified to see that both Ed Bott and Lifehacker (who picked this up from Ed) have noticed this feature, it was a huge amount of fun to write. It was also my first experience using TDD (or rather a variant of TDD – instead of writing the test first then the code, I wrote the code and the test for the code at the exact same time) - based on my experiences, I’m totally sold on it as a development paradigm.

I was working on Win7 M1, working on the Capture Monitor feature (which enables the ability to listen to your portable media player on your PC speakers without requiring special hardware support). A good chunk of my time was spent working on the networkthrottling issue, it required a ton of effort on the part of everyone involved to get this issue fixed (it was a very tricky problem to solve).

Well, we shipped Windows 7, and now I’d like to talk about a few of my favorite features that were added by the Sound team. Most of them fit in the “make it just work the way it’s supposed to”, but a few are just cool.

I also want to call out some stuff that people probably are going to miss in the various Windows 7 reviews.

One of the areas I want to call out is the volume UI. There’s actually been a ton of work done on the volume UI in Windows 7, although most of it exists under the covers. For instance, the simple volume control (the one you get to with a single click from the volume notification area) uses what we call “flat buttons”.

Windows 7 Simple Volume UI:

Windows Vista Simple Volume UI:

Both the mute control and the device button are “flat buttons” – when you mouse over the buttons, the button surfaces:

By using the “flat buttons”, the UI continues to have the old functionality, but it visually appears cleaner. There have been a number of other changes to the simple volume UI. First off, we will now show more than one slider if you have more than one audio solution on your machine and you’re using both of them at the same time. This behavior is controlled by the new volume control options dialog:

As I mentioned above, the device icon is also a “flat button” – this enables one click access to the hardware properties for you audio solution.

The volume mixer has also changed slightly. You’ll notice the flat buttons for the device and mute immediately. We also added a flat button for the System Sounds which launches the system sounds applet.

Another subtle change to the volume mixer is that there are now meters for individual applications as well as for the master volume:

And finally, the volume mixer no longer flickers when resizing (yay!). Fixing the flicker was a problem that took a ton of effort (and I needed to ask the User team for help figuring out the problem) – the solution turned out to be simple but it took some serious digging to figure it out.