Homework for February 2

Just for the records, my first proposal was rejected by my fellow classmates. I wanted to study the possibilities and implications, how 2nd factor authentication tokens could act as primary authenticator, and tie this approach into an OpenID style cross-service environment.

My second individual proposal, regarding the project, is still undecided, whether we are going to implement it or not. Here is the first couple of lines from my previous homework, that describes my idea:

Motivation : In many cases, where more than 2 speakers are used to output sound in average, non-professional situation, the speakers are not balanced out correctly to produce the sound experience how it's meant to be. This tool would be a one-click, automated volume calibrator, that would - without any special equipment - configure all the speakers to an appropriate volume level, to provide an audio sweet-spot, centering the user.

As of today, we have still not agreed on the team and projects, regardless, I read my first "paper" (technically, it is a series of MSDN articles about Windows sound API) at http://msdn.microsoft.com/en-us/library/windows/desktop/dd370805

What I figured out, that we have to take particular attention, how Windows handles different types of audio sessions and controls. An Audio Endpoint Device refers to the speakers and microphones. The concept of an audio session is a little bit confusing. If I understood correctly, in our project, we need to modify the global mix, which is which combines all the session on the particular audio endpoint device, but on individual channel basis. The Windows Audio Session API (WASAPI) will be our friend for the next couple of weeks to come.

The major challenge will be to comply with all the Microsoft style and methodology in the audio-rendering system. Also because there are some modes, when a program might gain exclusive control over the audio device, our settings will be overwritten/ignored by some applications. This is something that we just have to accept, because we do not want to alter program behavior other than the system's audio configurations. The good thing is, that (as it seems for now) hardware-independent. We don't have to code anything hardware specific, if Windows handles the surround system as a 2.1 or above, we will be able to abstract everything, and let the system sort it out.

User Stories:

• As a user, I have to be able to install the software without administrative privileges.

• As a user, I have to be able to choose between input devices (if more than one present) for recording.

• As a user, I have to be able to choose between output devices (if more than one present) to configure.

• As a user, I have to be able to interrupt the configuration procedure at any point.

• As a user, I have to be able to verify / accept the proposed volume levels before finalizing them.

• As a user, I have to be able to adjust the proposed volume levels before finalizing them.

• As a user, I have to be able to modify the volume properties after the application finished and/or exited.

Thanks for reading
--
Balazs Makany