| 1b715dc663bd7155d996576774e487d31bf331f7 |
|
13-Apr-2010 |
Martin Hibdon <mah@android.com> |
Put the beep back into the voiceDialer
Bug: 2326485
Now the VoiceDialerActivity plays a beep just as it starts listening.
The hard part here is that we need the end of the beep to line up
pretty accurately with the start of the microphone listening.
If the beep happens before the microphone is listening, then the
user will start speaking too soon. If the beep happens after the
microphone is listening, then the sound corrupts the incoming sample.
The other difficulty is that the time to start the microphone varies
considerably from platform to platform, so there is no practical way
to time the beep so matches. So instead, the VoiceDialerActivity
will play the beep after the mic starts, and then pull the first part
of the audio sample off of the incoming stream.
The beep is 40 milliseconds long, but there is some lag in between
requesting the tone to play and getting it back on the mic.
Experimentally, pulling out the first 350 milliseconds of sample
removes the beep without losing too much else on both Passion
and Sholes.
Change-Id: I23cc8c1e3969fd94a27a44e9e0e8c4f0a5cd5c00
/packages/apps/VoiceDialer/src/com/android/voicedialer/RecognizerClient.java
|
| 7a55150b308ed03d41091e4c3ac693d6eb0ab145 |
|
24-Feb-2010 |
mah <mah@android.com> |
Improve bluetooth voicedialing support
Bug: 2432200
When using voicedialing without being able to see or interact with the
screen, it is more important to keep the number of matches small. There
is now a setting on the CommandRecognizerEngine called "minimizeResults".
If this is set, then the CommandRecognizerEngine will in most cases return
only the highest confidence result.
It will return multiple results only in the case where it is unsure which phone
to call a particular person on. When this occurs, the BluetoothVoiceDialer
will announce the person it is about to call, and which phone types are available
(i.e. home, work, mobile, other), then begin listening for the the user to
indicate which phone.
/packages/apps/VoiceDialer/src/com/android/voicedialer/RecognizerClient.java
|
| 64c64e7c25e6efe31fa53369ec49db442b68ff9a |
|
09-Feb-2010 |
mah <mah@android.com> |
Add initial support for Bluetooth voice dialing.
Bug: 2432200
This adds a new BluetoothVoiceDialerActivity,
because the flow for bluetooth is so different from the regular VoiceDialerActivity.
This involved breaking RecognizerEngine's direct dependence on VoiceDialerActivity to
make callbacks on. RecognizerEngine now makes callbacks on an interface called RecognizerClient,
which is implemented by several different helper classes for different reasons.
I've made RecognizerEngine an abstract base class, it handles some general setup, logging, etc.
but it is up to the subclasses to set up the grammar and handle the results when recognition
succeeds. There are currently two subclasses, the CommandRecognizerEngine recognizes
phrases to call people, dial numbers, and open applications. The YesNoRecognizerEngine recognizes
"yes" and "no".
Known issues as of this checkin:
* 8khz audio has not been validated, it's not certain that the Recognizer is getting a good audio stream.
* There is still a problem with audio routing, the TTS output switches randomly between the speaker and
the headset.
* only the simplest case is supported, there's not a clean solution when there are multiple
possible matches.
* there are cases where the activity really should wait for the TTS utterance to finish before
moving on.
* we don't have a solution for when the phone is locked and the user activates bluetooth voicedial.
* the flow may or may not be ideal, the "no matches, try again" option may not be useful. We will
let some people try this and then revisit the approach.
/packages/apps/VoiceDialer/src/com/android/voicedialer/RecognizerClient.java
|