Developing a Prototype Window s Mobile Application

Transcription

1 Developing a Prototype Window s Mobile Application (Part 1 of Snoozing Soundly through Snore recognition ) Riley Kotchorek, Mike Smith, Vahid Garousi University of Calgary, Canada Contact: Michael Smith, Electrical and Computer Engineering, University of Calgary +1 (403) smithmr@ucalgary.ca Spark describes itself as a blog, radio show, podcast and an ongoing conversation about technology and culture (cbc.ca/spark). The host Nora Young certainly does not look the techno geek part, but she has interviewed some pretty technologically savvy people since 2007! It was Nora s interview with Tapani Salmi (Podcast 49) about the HappyWakeUp cell phone application that got one of my bosses (Mike Smith) the most excited. The podcast explained how HappyWakeUp (happywakeup.com) used a cell phone to monitor the sounds of a sleeper s movement for the last half an hour before a planned wake up alarm call. This time consists of alternating deep sleep and arousal periods. Wake up during an arousal time, and you are refreshed. Wake up during a deep sleep period and you switch between two Snow White dwarf personalities Happy to Grumpy! When I joined Drs. Smith and Garousi s research group this summer I was informed that We reckon that HappyWakeUp might just be the surprise killer application of 2009 / If people could automatically get out on the right side of the bed in the morning then it might change the mood of the world. Perhaps there would be no more road rage! However, I remember Dr. Garousi sighing wistfully, the application only runs on Nokia and iphones. That means I can t use it as a case study for my course Testing for new technologies. We only have Windows Mobile phones in the teaching laboratories. You ll just have to write the code for an application we can use! Perhaps the previous conversation did not exactly happen that way. However, it s roughly why I ended up writing a prototype medical mobile application, The Snorecognizer, to help determine how often people snore when taking a snooze after eating supper. This application may sound a bit crazy. However, it addresses a problem that is real and capable of causing considerable financial losses at both business and societal levels. Snoring is related to sleep apnoea and is a major health issue across the world, The series of mobile applications I had to develop would form the first practical part of a software engineering course on the Reliable development of mobile medical devices. These applications would then be extended by future graduate students when investigating smart phone aids to help solve sleep deprivation issues. If you are interesting in learning more about the impact of sleep deprivation, I recommend books such as Sleep Thieves by Stanley Coren, Free Press. Described here is the first part of my work, building the initial Snorecognizer prototype at the Hello World level. I needed to be able to demonstrate how to write software to use the many basic features available on a PDA or smart phone. This meant that the prototype will have to accept input commands from the available keys and display text together with handling basic audio operations. By doing some basic DSP analysis on the monitored input sounds, the final cell phone Snorecognizer will output graphs on the maximum number of snores per snooze and other useful pieces of Hey, you re snoring! information gathered. Selecting a Cell Phone OS Before saying hello to this new world, I needed to choose a target platform and an environment to develop in. There are many different smart phone and PDA platforms available, each with its own pros and cons.

2 Most of the existing mobile operating system (OS) options have free or inexpensive development environments. Some platforms run Java based applications, while others run C, C# or C++. With all of the different choices available, we chose Windows Mobile because the University of Calgary has licenses for Microsoft s Visual Studio 2008 in place. The code could be first tested using the emulators that come packaged with the Windows Mobile SDKs (Software Development Kits). Finally the code could be moved to UTStarcom devices for use in the class room. Another advantage was that Windows Mobile applications can be developed using the same C / C++ language that the undergraduates other embedded system courses used. A full version of Microsoft Visual Studio can be expensive for somebody who just wants to start playing around with mobile devices. However a fully functional, 90 trial version of Visual Studio 2008 Professional is available on Microsoft s site ( downloads). you have a HP ipaq RX5910 GPS device running Windows Mobile 5.0 for Pocket PC you want to get the Windows Mobile 5.0 SDK for Pocket PC. A Hello world! capable prototype Just getting started in any new environment always seems to be the most difficult part of a new project. I will detail how to make a basic Mobile windowed application which prints an Oy you you re snoring! message to the mobile devices screen (see Photo 1). To begin, we create a new project in Visual Studio by selecting File > New > Project from the menu bar. Next, we need to choose Visual C++ Smart Device as our project type (Photo 2) and then Win32 Smart Device Project as the template. After clicking Ok, we have to select the software development kit that corresponds to the device s Windows Mobile version. Our device uses Windows Mobile 5.0 for Pocket PC so I used Windows Mobile 5.0 Pocket PC SDK. The application type should be set to Windows application. Photo 1 The first prototype requires that a simple message to be displayed in the application s window A useful source of code ideas can be found from the Microsoft Developer Network function descriptions/usage guides (msdn.microsoft.com/). The Windows Mobile SDKs are also available on the same download site at no charge. Remember to get the SDK which matches your target device s Windows Mobile version. For example, if Photo 2 New Project Wizard settings in order to create a C++ project for a Windows Mobile device

3 Clicking on the finish button causes Visual Studio to generate a large portion of the code for us. The WinMain( ) function, the entry point into the application, continuously listens to the messages sent to it by the mobile operating system when events (interrupts) occur. These messages are then dispatched to the WndProc( ) callback function. This main user code entry point is where the messages are deciphered and then the appropriate action taken. The default WndProc( ) procedure generated by Visual Studio is nothing more than a large switch statement (Listing 1) based on which event message (wmessage) (Line 9) has been sent by the mobile operating system to the application. There are standard cases that are called when the application starts and finishes (WM_CREATE (Line 13) and WM_DESTROY (Line 14)). For our code, we want to make the WndProc( ) function responsible for painting our greeting message onto the application s main window (see Photo 1). When the OS receives a request to repaint this window it sends a WM_PAINT message to the application. Deciphering of this incoming wmessage message is done in the WndProc( ) function by the WM_PAINT case in switch(wmessage) (Listing 1). The case statement starts by calling the BeginPaint( ) function (Line 21). This function takes a handle to the window hwnd we want to paint, and a pointer to a PAINTSTRUCT structure. It returns a handle to information about the device context (DC). This DC defines the screen area which will be affected by the paint operation, which in this case is the client 1 LRESULT CALLBACK WndProc(HWND hwnd, UINT wmessage, 2 WPARAM wparam, LPARAM lparam) { 3 // WndProc variable declarations 4 PAINTSTRUCT ps; 5 HDC hdc; 6 TCHAR outputstring[ ] = L"Oy you you re snoring!"; 7 _8 // switch statement to interpret the message from Windows OS 9 switch(wmessage) { // Code for handling wmessages sent the when application 12 // starts and finished 13 case WM_CREATE: etc; break; case WM_DESTROY: etc; break; // A WM_PAINT message occurs when the operating 18 // system wants to refresh or "paint" a window 19 case WM_PAINT: 20 // Prepare window for painting and get a handle to the DC 21 hdc = BeginPaint(hWnd, &ps); // Get info on application window's size 24 RECT windowsize; 25 GetClientRect(hWnd, &windowsize); // Immediately draw the text to the known screen area 28 DrawText(hdc, outputstring, 29-1, windowsize, DT_CENTER DT_WORDBREAK); // End the painting session for the window 32 EndPaint(hWnd, &ps); break; 35 } // End switch(wmessage) 36 return 0; 37 } // End WndProc( ) Listing 1 Implementation of a basic Hello world! operation inside the WM_PAINT case of the switch(wmessage) statement in the WndProc( ) callback function in our mobile application area of our mobile device s window. Next, we need details of the area on the screen into which we want to place our text. For this particular case we call GetClientRect( ) (Line 25) and pass in a handle to the window. We get back a rectangle variable, windowsize, filled with details about the client window. DrawText( ) is then called to write our hello world text, "Oy you you re snoring!" into the area defined by our rectangle and the device context (Lines 28 and 29). The L leading the string passed to the DrawText( ) function is an indication that this string should be created with wide characters (TCHAR Unicode symbol) that take 2 bytes of storage instead of just 1. Using TCHAR means that the application can be adapted to a wide range of languages The third parameter 1 indicates the use of a null terminated string and avoids the need to specify the precise length of the string. The DT_CENTER and DT_WORDBREAK flags passed in the fifth argument to DrawText( ) tell the system to centre the text horizontally and wrap the text to the next line if it goes outside of the rectangle specified in argument 4. Each call to BeginPaint( ) must be followed by an EndPaint( )

4 call (Line 32) to complete the painting processes. These functions can only be called inside the WM_PAINT case. Debugging Now that we have the basic Snorecognizer prototype coded and we need to test it. There are two approaches to debugging the code: Running the application on (1) an emulator and later (2) when we have a real device available to work with. Choosing whether to run an emulator or debug an application directly on a physical device can be done in the target device drop down menu (Photo 3). If you can t find the target device menu amongst your toolbars, it can be enabled by selecting View > Toolbars > Device from the menu bar. We can begin running the application on one of the Windows Mobile device emulators supplied as part of the Microsoft SDKs. We can do this by first selecting Build > Build Solution from the menu bar and fixing any typo errors that pop up. The second step is to choose Debug > Start Debugging from the same menus. The appropriate Windows Mobile emulator will activate and, after the program has been transferred to the emulator, it will display our message (Photo 1). Click on the OK button (see Photo 1) to stop the application. Since this is a mobile device, clicking on the X at the top of the screen just minimizes the application rather than stopping it as would happen on a desktop. Remember that minimized mobile applications still consume power. An emulator is all fine and dandy, but on device debugging is the proverbial meat and potatoes when testing mobile applications. To do this you will need three more things: (1) the free program Microsoft ActiveSync if running under XP or Windows Mobile Device Centre if you re programming on Windows Vista; (2) a cable to connect the device to the computer and (3) a mobile device itself. In our case we first used the GPS capable HP ipaq rx5910 loaded with Windows Mobile 5.0 for Pocket PC donated by a local company To get started with on device testing, first connect your device to the computer; and wait until ActiveSync / Windows Mobile Device Centre recognizes and syncs to it. Next, back in the Visual Studio Development Environment, again select your project. However this time choose the device option from the drop down target device selection menu (Photo 3). Now simply follow the same Build / Debug procedure we used when running on an emulator. Photo 3 This screenshot shows the options available in the drop down target device list. The only difference between the two emulator options is that one will have a square display and the other will have a standard rectangular display. The third option will run the code on a physical device connected via ActiveSync or Windows Mobile Device Center

5 Recognizing key strokes The final Snorecognizer project will need more than just the ability to print out a simple warning Oy you you re snoring message. The user will need to use the mobile device s keys to control its operation. We can demonstrate this additional functionality by having the application output different messages to the screen according to which button has been pressed. Unlike a desk top or lap top PC with its key board, mobile devices have relatively few buttons. Pressing any of these keys causes a WM_KEYDOWN message to be sent to the WndProc( ) function. See Listing 2 (Lines 11 to 29) for details on how the WM_KEYDOWN message is handled. Detailed information about each WM_KEYDOWN message is contained in the wparam and lparam arguments passed to WndProc( ) (Line 1)The wparam variable contains a code corresponding to which key has been pressed. The lparam variable contains additional information about the key press, such as whether or not the key has been pressed and released or is being held down (we will need this information later on). Using the Keys certain aspects of the our WndProc( ) function (Listing 2). To enable the WM_PAINT event to display different messages, we need to be able to change the TCHAR string array used by the DrawText( ) function inside the WM_PAINT case statement. This allows us to modify what is displayed on the screen when a button is pressed. Now we need to create a new case inside the switch(wmessage) statement of WndProc( ) to handle WM_KEYDOWN messages. This gives the application the ability to recognize key press detection. Inside this new case statement, wparam is compared to the Window s constants VK_RIGHT (right arrow, Line 14) and VK_LEFT (left arrow, Line 18) in order to decipher which key has been pressed. Our outputstring (Line 4) can then be modified to display a different message using wsprintf( ). The wsprintf( ) function differs from the standard sprintf( ) write to a string 1 LRESULT CALLBACK WndProc(HWND hwnd, UINT wmessage, 2 WPARAM wparam, LPARAM lparam) { 3 // WndProc variable declarations 4 static TCHAR outputstring[100] = L"Welcome to the Snorecognizer"; 5 // etc 6 7 switch (wmessage) { 8 9 // VK_RIGHT and VK_LEFT are virtual-key codes for the 10 // right and left keys (set by the operating system) 11 case WM_KEYDOWN: 12 switch(wparam) { case VK_RIGHT: // Change global output string 15 wsprintf(outputstring, L"Recording the audio ); 16 break; case VK_LEFT: 19 wsprintf(outputstring, L"Playing back recorded audio"); 20 break; // Let all other keys retain their standard functionality 23 default: 24 return DefWindowProc(hWnd, message, wparam, lparam); 25 } // switch(wparam) // Tell the operating system that hwnd window needs updating 28 InvalidateRect(hWnd, NULL, TRUE); 29 break; // New WM_PAINT message displays text from a local static object. 32 case WM_PAINT: 33 hdc = BeginPaint(hWnd, &ps);. break; // Code for interpreting other wmessages case WM_CREATE: etc; break; } // End switch(wmessage) } // End WndProc( ) To demonstrate using the keys we have to modify Listing 2 New WM_KEYDOWN case in switch(wmessage) statement inside WndProc( ) function changes the message displayed on the screen based on user input via buttons

6 buffer function in that it handles the wide Unicode enabled characters rather than standard 8 bit characters. The default case of the WM_KEYDOWN message (Line 23) activates the DefWindowProc( ) function. This informs the OS that it is to perform the default action corresponding to the current key press. This is a better programming style than just setting the default case code to default: /* DO NOTHING */ break; which would not allow any other device keys to function properly. We now need to force the mobile OS to issue a WM_PAINT message to update the device s display window. This is done in Line 28 by passing the InvalidateRect( ) function a handle, hwnd, to the window we want to invalidate (redraw). Setting the second parameter to NULL causes the window s entire client area to be updated, rather than just part of it. The last argument of InvalidateRect( ) is set to TRUE so as to erase the background before painting over it. Setting this parameter to FALSE will cause the new text to be written without erasing the previously displayed message first. Running the program with these changes will display the welcome message on the screen initially. Pressing the LEFT or RIGHT arrow keys will cause a change between playback and recording messages respectively. Using Audio In /Out Devices The final stage in this Snorecognizer prototype is to demonstrate that we understand the basic usage of the mobile OS waveform audio input and output devices. In the case of Windows Mobile, the devices used will be the built in microphone and speakers. Listing 3 shows the modification of the WM_KEYDOWN events so that the application will record a sound and then play it back. There are four functions that need to be controlled start and stop the recording and start and stop the play back. The user interface would be intuitive if we used one press of the RIGHT key to start recording, and a second press to stop the recording with the LEFT key starting and stopping the play back. We ll also initially limit the audio operation to recording and playing back five seconds of sound into a specified buffer. The application will stop recording/play back either when the user tells it to (second key press) or when it reaches the end of the buffer, whichever comes first. The first lines in Listing 3 show static variables needed for the new WndProc( ) function. The state variables playing and recording will keep track of the application s current play/record state. Device handles to the audio in/out devices hwavein and hwaveout are used to identify each device (Lines 5 and 6). The WAVEHDR structures will hold information regarding the audio buffer, as well as a pointer to the buffer itself We will only be using one buffer to hold the audio information. This means that in the prototype the user will not be able to play and record at the same time. Two WAVEHDR structures are required; one header used by the audio in device and other by the audio out device (Lines 7 and 8). Both headers will use a pointer to the same audio buffer. We can now make use of the lparam variable which contains additional information about the WM_KEYDOWN message. In Listing 2, we changed the display for each WM_KEYDOWN message. It did not really matter if the user has been accidently holding down a key for long enough to activate the key s REPEAT functionality. Now in this new prototype we don t want to recognize a second WM_KEYDOWN event until the user has physically released the key.

7 We can avoid this REPEAT operation gotcha by checking the PREVIOUSLY_DOWN_MASK bit of the lparam (Line 15). If this bit is not zero we don t want to reexecute the case statement as the application (or is it the user? ) is in the repeat key stroke mode If the RIGHT key has been pressed for the first time, we want to start recording (Line 17). This involves using waveinaddbuffer( ) to tell the OS to add a new buffer to the audio input (wave) queue (Line 21). Then the audio device is activated (waveinstart( ), Line 24) and the user informed that recording has started. A second press of the RIGHT key causes the recording to stop (waveinreset( ) (Line 32)). In a similar way, the LEFT key is used to control the wave output device. The waveoutwrite( ) function handles both queuing the buffer and starting the output audio device (Line 40). Audio Device Initialization When the window for the application is first created, a WM_CREATE message is sent to the WndProc( ) function by the OS. In the default code, WM_CREATE is used to create the OK and HELP menu at the bottom of the application window (see Photo 1). We need to place additional code in this case statement to set up the audio devices (see Listing 4). The inserted code has a straight forward logical flow. The string and state variables are set to their initial values. Both input and output buffer headers are then zeroed to avoid causing errors down the road. The lpdata member of the WAVEHDR structures will point to 1 // Mask used to check if a key is being held down 2 #define PREVIOUSLY_DOWN_MASK 0x // WndProc variable declarations 4 static int recording = 0, playing = 0; 5 static HWAVEIN hwavein; 6 static HWAVEOUT hwaveout; 7 static WAVEHDR waveoutbufferheader; 8 static WAVEHDR waveinbufferheader; 9 // etc switch (wmessage) { 12 case WM_KEYDOWN: 13 // Check the PREVIOUSLY_DOWN bit of lparam to ensure we do 14 // not repeat actions if the button is held down 15 if ((lparam & PREVIOUSLY_DOWN_MASK) == 0) { 16 switch(wparam) { 17 case VK_RIGHT: //The user has selected record 18 // Record if not already recording or playing 19 if (!playing &&!recording){ 20 recording = 1; 21 waveinaddbuffer(hwavein, &waveinbufferheader, 22 sizeof(wavehdr)); waveinstart(hwavein); wsprintf(outputstring, L"Recording Audio"); 27 InvalidateRect(hWnd, NULL, TRUE); 28 } 29 // else if we are currently recording and want to stop 30 else if (!playing && recording) { 31 recording = 0; 32 waveinreset(hwavein); 33 } 34 break; case VK_LEFT: //The user has selected play 37 // If we aren't already recording or playing 38 if (!recording &&!playing){ 39 playing = 1; 40 waveoutwrite(hwaveout, &waveoutbufferheader, 41 sizeof(wavehdr)); wsprintf(outputstring, 44 L"Playing back recorded audio"); 45 InvalidateRect(hWnd, NULL, TRUE); 46 } 47 //else if we are currently playing and want to stop 48 else if (!recording && playing) { 49 playing = 0; 50 waveoutreset(hwaveout); 51 } 52 break; default: 55 return DefWindowProc(hWnd, message, wparam, lparam); 56 } // End switch(wparam); 57 } // if ((lparam & PREVIOUSLY_DOWN_MASK) == 0) 58 else 59 return DefWindowProc(hWnd, message, wparam, lparam); break; // End case WM_KEYDOWN: case WM_PAINT: etc; break; } // End switch(wmessage) Listing 3 Modifying the WM_KEYDOWN case of the switch(wmessage) statement inside WndProc( ) function starts and stops the audio devices based.

8 the audio buffer, which we have to allocate. Although the audio buffer is made up of signed short integer (16 bit) values, the dwbufferlength value must be expressed in bytes; another gotcha to be avoided in Lines 115 and 116. The buffer itself needs to be zeroed to avoid producing painful sounds when the output device is first activated. Next, we fill a WAVEFORMATEX structure with audio format information defined in Listing 5. The format structure is then passed to the waveinopen( ) and waveoutopen( ) functions which specifies our selected audio format to the audio devices (lines 131 and 133). The waveinopen( ) and waveoutopen( ) functions open handles to the microphone and speaker(s), respectively. We pass a pointer to the handle we wish to populate (hwavein or hwaveout) as the first argument to these 100 case WM_CREATE: 101 // Setup the initial message and state variables 102 wsprintf(outputstring, 103 L"Welcome to the Snorecognizer"); 104 recording = 0; 105 playing = 0; // Zero the buffer header structures (will cause errors 108 // if not done) 109 memset(&waveinbufferheader, 0, sizeof(wavehdr)); 110 memset(&waveoutbufferheader, 0, sizeof(wavehdr)); // Allocate and zero the audio buffer 113 waveinbufferheader.lpdata = new char[audiobuffersize]; 114 waveoutbufferheader.lpdata = waveinbufferheader.lpdata; 115 waveinbufferheader.dwbufferlength = AUDIOBUFFERSIZE; 116 waveoutbufferheader.dwbufferlength = AUDIOBUFFERSIZE; memset(waveinbufferheader.lpdata, 0, AUDIOBUFFERSIZE); // Setup the audio format based on pre-defined values 121 WAVEFORMATEX waveformat; 122 waveformat.wformattag = CHOSEN_WAVE_FORMAT; 123 waveformat.nchannels = CHANNELS; 124 waveformat.nsamplespersec = SAMPLES_PER_SEC; 125 waveformat.navgbytespersec = AVG_BYTES_PER_SEC; 126 waveformat.nblockalign = BLOCK_ALIGN; 127 waveformat.wbitspersample = BITS_PER_SAMPLE; 128 waveformat.cbsize = CBSIZE; // Open connections to the audio devices 131 waveinopen(&hwavein, 0, &waveformat, (DWORD) hwnd, 0, 132 CALLBACK_WINDOW); 133 waveoutopen(&hwaveout, 0, &waveformat, (DWORD) hwnd, 0, 134 CALLBACK_WINDOW); // Prepare the headers 137 waveinprepareheader(hwavein, &waveinbufferheader, 138 sizeof(wavehdr)); 139 waveoutprepareheader(hwaveout, &waveoutbufferheader, 140 sizeof(wavehdr)); // Code already in WM_CREATE (generated by Visual Studio) 143 // to handle the application menus break; Listing 4 New code inserted into WM_CREATE case in the WndProc( ) function s switch(wmessage) statement to initialize the buffer and audio devices functions. The second argument specifies which audio in/out device we would like to use, although there s a good chance your device only has one. The audio format is specified by the third argument a pointer to our WAVEFORMATEX structure. The audio devices themselves are capable of sending messages (much like WM_KEYDOWN) to a callback mechanism. The fourth and sixth arguments of waveinopen( ) and waveoutopen( ) tell the system to send any messages from the audio devices to our application s WndProc( ) function. The fifth argument is saved for any custom data and is not currently used. Now that we have opened the device handles, we must prepare the buffer headers. This is done using the waveinprepareheader( ) and waveoutprepareheader( ) functions (Lines 137 and 138). We pass the device handles, hwavein and hwaveout, to the functions to identify which devices we are referring to. The second argument is a pointer to the header we want to prepare. In addition, we must specify the size of the header, which is passed in the third argument. Completed Buffers Now that we are in the position to be able to start recording and playback, how can we tell if an audio device has completed filling or emptying its buffer? We need this information to be able to update the screen with a done message to the user, but how? The route to solving this problem is the parameter CALLBACK_WINDOW used in the waveinopen( ) and waveoutopen( ) functions in Listing

9 4 (Lines 132 and 134). This specifies that our program window is to be the callback mechanism for any messages from the audio devices. Because of this, when the wave out device finishes with a buffer it will send a MM_WOM_DONE message to the WndProc( ) function. We can create a new case inside the main WndProc( ) switch statement (see Listing 6, Line 60) for this message in order to update outputstring. Equivalently, the MM_WIM_DATA (Line 66) message is sent when the wave in device has finished with its buffer. // Pulse Code Modulation format #define CHOSEN_WAVE_FORMAT WAVE_FORMAT_PCM // Mono audio with 44.1kHz sampling rate, 2 bytes per sample #define CHANNELS 1 #define SAMPLES_PER_SEC #define BITS_PER_SAMPLE 16 // 2 bytes per block #define BLOCK_ALIGN (((CHANNELS) * (BITS_PER_SAMPLE)) / 8) // 88,200 bytes per second #define AVG_BYTES_PER_SEC ((SAMPLES_PER_SEC) * (BLOCK_ALIGN)) // 5 second audio buffer size #define AUDIOBUFFERSIZE (5 * AVG_BYTES_PER_SEC) // Size in bytes of any extra space at the end of the // WAVEFORMATEX structure for additional user info #define CBSIZE 0 Listing 5 Definitions used to set the audio format and audio buffer size placed inside Snorecognizer.h file which is included in the main Snorecognizer.cpp file Application closedown With the current code, the mobile device will be left in an inoperable situation for other applications when the user clicks OK to exit the Snorecognizer prototype. For example, we have allocated a buffer in WM_CREATE. If this is not released, then exiting the code will generate a memory leak. In addition, if we prepare a buffer header for a device and forget to unprepare it, it will remain with the device even if our program exits! Once the audio device has been filled with prepared headers, it will refuse additional buffer headers, requiring a hard reset of the system. In order to avoid these troublesome errors, we should ensure our program properly cleans up after itself. (Reminds me of what my great great Aunt Agatha always used to tell me about tidying my room.) We will have to release the audio buffer, unprepare" the buffer headers and close the audio device handles. All of this can be accomplished inside the WM_DESTROY case of the //case for when the waveout device has finished playback 60 case MM_WOM_DONE: 61 wsprintf(outputstring, L"Audio recording complete"); 62 InvalidateRect(hWnd, NULL, TRUE); 63 break; //case for when the wavein device has finished recording 66 case MM_WIM_DATA: 67 wsprintf(outputstring, L"Playback complete"); 68 InvalidateRect(hWnd, NULL, TRUE); 69 break; Listing 6 New cases added to the WndProc( ) function s switch(wmessage) statement to handle messages sent when the audio devices finish reading/writing their buffers 70 case WM_DESTROY: 71 // Force the devices to stop what they are doing 72 // and return the queued buffer(s) to the 73 // application 74 waveoutreset(hwaveout); 75 waveinreset(hwavein); // Unprepare both headers 78 waveoutunprepareheader(hwaveout, &waveoutbufferheader, 79 sizeof(wavehdr)); 80 waveinunprepareheader(hwavein, &waveinbufferheader, 81 sizeof(wavehdr)); // Close the device connections 84 waveoutclose(hwaveout); 85 waveinclose(hwavein); // Remove the audio buffer 88 delete [] waveinbufferheader.lpdata; // Code already in WM_DESTROY (generated By Visual Studio) // to destroy the basic application menu break; Listing 7 New code inserted into WM_DESTROY case in the WndProc( ) function s switch(wmessage) statement to cleanup allocated memory and close audio device connections

10 WndProc( ) function s main switch statement (See Listing 7). A WM_DESTROY message is sent to WndProc( ) whenever the window is destroyed (Line 70) This mirrors our initialization code we wrote for the WM_CREATE message. The main gotcha to avoid is to release things in WM_DESTROY in the exact opposite order to which they were created in WM_CREATE. For example, the handles become useless after they have been closed. With clean code, the window can close without worry of a memory leak or other errors. Where to next? In this article we set out to demonstrate a simple prototype for our soon to be complete Snorecognizer Windows Mobile application. So far, the Snorecognizer handles basic key input / screen output as well as controlling the onboard audio devices on a Windows Mobile device. I hope you enjoyed this article. Coming up in the second article we ll delve further into the world of Windows Mobile and Snore Recognition. We will demonstrate how to expand the prototype s functionality to include simple audio DSP, handling audio operations over a long period of time and even showing our grasp of general graphing of the results! Acknowledgements We would like to thank DirectVoxx (Calgary) and Telus (Canada) for arranging the donation of the mobile equipment used in this article. The Snorecognizer application was a spin off from Riley s research on the development of testing tools for mobile devices. This work was supported through a Natural Sciences and Engineering Research Council (NSERC) of Canada Undergraduate Student Research scholarship and by additional funding through Dr. Garousi s Award Alberta Ingenuity New Faculty Award no We also thank Lizie Dunling Smith for her editorial suggestions in making the article more readable. About the Authors Riley Kotchorek is a NSERC Undergraduate Student Research Award recipient. When he s not playing the latest video game he enjoys programming in C# and Java. He will be returning to the University of Calgary, Canada in Fall 2009 to finish his fourth year in computer engineering. Mike Smith has a strong interest in the fields of Biomedical and Computer Engineering and holds a firm belief that agile methodologies, such as test driven development, are a route to lower defects in mobile systems. Mike s sense of humour often appears in his frequent contributions to Circuit Cellar. He is a professor at the University of Calgary, Canada and is director of the SMILE laboratory (SMILE standing for Small Microsystems for Improving Life Expectancy.) Vahid Garousi is an Assistant Professor of Software Engineering at the University of Calgary. He leads a team of research associates and students in the Software Quality Engineering Research Group (SoftQual). This group focuses on techniques to improve upon existing methodologies and develop new approaches in the production of industrial software.