Chatter Box Daniel Dunham Nick Noack Mike Nelson

Overview Project description Usage scenario Project components Important issues Division of labor Schedule and milestones

Project Concept Interfaces to the personal server ‘Standard’ Visual display with keyboard/keypad Alternative Audio based I/O via cell phone

Why Use Audio? Speech is an easy, natural way for people to receive and provide input Cell phones are commonplace Cell phones already being built with Bluetooth capability

Project Goals Simulate a cell phone for audio recording and transmission Develop the personal server audio interface Develop an application to exhibit the audio capabilities

Cell Phone Simulator Ideal project would use a real cell phone Cell phone software is proprietary Hence, prototype using a tablet with microphone, speakers, number pad

Audio Development Audio support will be developed incrementally Along the way some basic useful applications are realized

Audio: First Step Transmission to and storage of audio data on the personal server Application: memo device User records notes (speaking into phone) At a later time user listens to notes – meetings, thoughts, etc

Audio: Second Step Text-to-speech support Important aspect of an audio interface Application: book reader Take a book in text format and read to the user with a synthesized voice

Audio: Final Step Text-to-speech is one direction of the I/O Other direction: speech-to-text More difficult than text-to-speech Settle initially for speech-command recognition

Application for the Audio Numerous potential applications, as seen already Our personal favorite: provide people with a tool to view dining options

Restaurant Selector Restaurants broadcast menus over short-range radio link Personal server receives menus, adding them to a database of menus If the person is hungry, they access their personal server (via PDA, kiosk, phone, etc)

A Sea of Options Application helps to narrow them down

Restaurant Selector Features User can input dietary preferences/restrictions to narrow down the options they will be shown On a diet? Specify caloric limit, cholesterol limit, etc Restaurant selector only shows you what you can (or should) eat Remove temptations before you see them

Restaurant Selector Features User specifies with spoken commands what he wants “Find Italian please” “Price limit seven dollars por favor” Speech recognition matches request to a set of commands and displays restaurants meeting the specifications May require training

Restaurant Selector Features Add-on: GPS Allows added search constraint based on distance of user from restaurant If we get bored, add some navigational assistance

Usage Scenario Joe the hip, happening college student Owns a personal server (naturally) Goes to the Ave looking for food Dials up his personal server Brings up a list of Thai restaurants Joe’s allergic to peanuts His personal server knows this Later in Sieg, Joe’s friends are hungry too

Important Issues Text-to-speech and speech-to-text still an untested black box Restaurant search options: how much do we allow/require from restaurants Example: Will restaurants have precise nutritional information? Key: Allow easy change

Project Summary Audio interface Text-to-speech, command recognition Restaurant selector Dietary preference specification Constrained searching Project components Hardware, audio, restaurant app

Project Summary Major issues Speech-to-text Restaurant filtering specifics Division of labor Audio: primarily Nick Restaurant filtering app: primarily Mike Hardware: primarily Daniel