Changing the Default Sound Device

About a year ago I bought for myself a new 24-inch monitor. It is great for games work as you can work with a lot of documents/source code files together without having to scroll around and/or toggle between many windows. What was great about this monitor, was that it had an HDMI port. “So what?” you will say and you will be right, but for me it was a revelation, especially when I upgraded my graphics card and bought one which had an HDMI output.

Although regarding graphics there was no difference transitioning from DVI to HDMI the sound was a whole new experience. As with anything in this life, when you get something you have to give something in return. What happened was that there was a new sound device in my setup, so my headphones could not function in parallel to the monitor speakers.

Changing from one to the other is not very difficult, but you have to access the playback devices tab in the sound configuration and set the device you want to use as the default. Searching the net you can find many guides and solutions to this problem. Some with screenshots showing the windows way:

And some more suited to power users/programmers:

Running a command line or having a shortcut (that I usually don’t remember) is not my thing, so building upon the work of the aforementioned people I decided to create an application that lives on the tray, is easy to access and helps me change easily between my monitor speakers and headphones. Let me present you with the aptly named ChangeSoundDevice program.


Before you use the application make sure that you have downloaded and installed the Microsoft Visual C++ 2010 Redistributable Package (x86). The first time that you will launch the program, it will automatically pop up a window listing the devices it has found in your system.


You can edit the names (to make them shorter and friendlier) and hit the OK Button. By default the first time the program is launched the first device will be chosen, but you can now change it easily with two clicks. One to the tray icon and one to the device of your choice. The following screenshot shows the user interface for this window.


You can also use the find devices button to get the first window again. This can be useful if you have a new sound device or are not satisfied with the previous naming.

Warning: Geeky Stuff

After having used code that was freely given by the aforementioned sites, it would be only fair to publish the source code of my application too. Inside the source code bundle you will find a solution with 2 projects. The first is a native dll library that is mostly a copy of Dave Amenta’s code with a few changes to make it play nice with P/Invoke. The second is the main program that uses the native library and runs in the tray.

Note that there is an error with the P/Invoke signatures, that I couldn’t resolve. Even though it works, there is some problem that gets caught in the debugger.

You can get the source code here.


Get the applicationhere

The difference between a prototype and a product

One of the common themes that keeps popping up lately in my line of work is the difference between a product and a prototype. A prototype is something that you make for yourself. Something that only you will use (or select few with specific instructions), something that does a very specific job and will probably crash your hard drive and burn your dvd player if you try to make any changes.

A few simple examples of this are renaming of files/folders, some csv file data “massage” or anything that is repeatable. The development time is usually short enough to warrant that you won’t spend more time doing the development than the time you gain from doing this work manually. This can scale up to include machines that cost a few thousands of Euros, like the ones which we make at my workplace for in-house use. The pattern is the same no matter what the complexity is. Let me share some of my experience as it relates to software development.

There are some times when the result is so good, that you want to share this thing with the community or sell it. That is when you hit a brick wall. Your prototype program that renames all files and replaces an underscore with a space did a great job for you, but what about those that have files with dots? What happens when you have two underscores? Not to mention the more complex scenarios.

This is what I call the gray zone. It is a place of pain, where you don’t have significant gains as far as important features are concerned, but you keep pouring effort into. It is a disproportionately long and demanding effort, before you are able to transition to the product area, where you can give the thing you are developing to someone else. See the following graph (made by matplotlib and edited by for an visual depiction of this.

Prototype-Product Graph

This is a clear example of the Pareto Principle or the 80-20 rule.

The Pareto principle (also known as the 80–20 rule, the law of the vital few, and the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes.


Although this principle has its roots in economics, you can find applications of this in many real life scenarios like businesses, demographics and software engineering to name a few. In our case, you can spend 20 percent of the total development time to achieve 80 percent functionality, but the rest 20 percent of functionality is what makes a product shine. It can make all the difference in terms of having happy “clients” (either paying ones, or not –friends,family,community).

For example you can have software which when crashes, shows the following screens:



Guess which is a product. One gives you some cryptic information that probably even the author of the application wouldn’t use. The other apologizes for the crash, promises to get some of your work back and asks if you want to contribute towards the fix of the problem that created your crash by sending data that is useful to the ones who wrote the application.

When you are in the prototype phase you don’t care about such things. If there is a crash, then you probably already have attached a debugger, or you make a mental note to do so next time. Also, you know and expect what you will be doing with your program. If you write a division program you won’t be putting any zeroes to the divisor textbox, will you? When you give your software to others though, nobody can assure you that they won’t. In fact, you can be assured that they will.

If you like your product to have an impact you have to trudge through the Gray zone, now matter how difficult –or boring- it may seem. It really makes a world of difference. When you manage to break through the Gray zone, then –oh joy- you are ready to reap the rewards of your hard work, be it a friendly pat in the back (even a good comment on twitter qualifies as one), a big pile of money or anything between those.

As far as I am concerned, there are at least 4-5 projects/relevant posts that are somewhere in the middle of the gray zone. Hopefully you will hear of them soon.