The Google Voice Search comes with a significant delay from the moment you call it via startActivityForResult() until its dialog box is displayed, ready to take your speech.
This requires the user to always look at the screen, waiting for the dialog box to be displayed, before speaking.
It would be nice to add a 'ding' sound or some other non-visual cue to when Voice Search is ready to accept speech input.
Is this possible at all?
If so, how do go about doing that?
Ok this will complicate your program, however, if you really want that signal consider implementing the speech recognition by an object instead of calling the intent or making your own activity.
(warning: much of this is speculation including the order of calls)
Perhaps the delay is in instantiating resources before actually listening. If my theory is correct than you could setRecognitionListener(RecognitionListener listener) (the latency passes), create a recognizerIntent object (maybe some more latency passes), finally in (an overridden) startListening(Intent recognizerIntent), call a "PING!" before calling the super method.
It is up to you whether you would like to wrap all this functionality in a new activity, which is probably recommended, or to tack on the latency to the UI.
Related
In terms of performance and usability, what is the best approach? What are the main differences between these two methods?
I currently have an implementation on "OnResults" that is constantly listening and compares with a couple strings, taking distinct actions for each word detected. However, it fails on recognizing the words some times and sometimes doesn't even listen to anything. If I moved the logic to "OnPartialResults" would improve the usability?
onResults is called when SpeechRecognizer finishes listening.
onPartialResults is called when SpeechRecognizer detect new word you have spoken, even before end of listening.
Both of them should have got the same results for single spoken words, but if your speech is longer, onResults can modify your output to make it little more grammatically correct (but just little bit).
Usage of them depends of your purposes. But more accuratrate results are given with onResults.
If you want to match spoken words to action, create own matcher, which would choose the best matching (but not always equal, because it does not work always).
More about onResults and onPartialResults at developer.android.com
Important: to get partial results, you have to add extra to recognizer intent:
intent.putExtra(RecognizerIntent.EXTRA_PARTIAL_RESULTS, true);
I am using Android TTS to speak a text. The speaking is done on a service. I am using TTS..speak(toSpeak, TextToSpeech.QUEUE_FLUSH, null); my speak() function is called several times, during intervals. Because it is a service, its possible that other sounds are playing while speak() is called.
I want to know how to 'silence' those other sounds WHILE my text is being spoken.
The term you need to search for is 'audio ducking'. It's not an obvious one, so you can be forgiven for not finding any solutions with other search terms!
Check out the suggested way to handle this in the tutorial here.
I assume you will want to just lower any other media volume so the speech can be heard = ducking.
AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK
Alternatively, you can request that other apps silence any media, until your onUtteranceCompleted is called and you release the audio focus. Beware though, if the other apps aren't handling the loss and gain of focus correctly, their media will not restart and your user will probably be annoyed...
When a SpeechRecognizer is processing an input sound, it takes a moment to be responsive again. I am intending to start a second SpeechRecognizer right when the first one calls onEndOfSpeech() to be responsive all the time but I am getting ERROR_RECOGNIZER_BUSY. I might be doing something wrong or it's just that only one SpeechRecognizer can be working at a time.
Does anyone knows if this is possible?
By the way, the speech recognizers I created are services, so there is no GUI.
I am trying to write an app that detects whenever any app on the device starts or stops playing music. My app is not a media player, it's more of a dashboard functionality, so I have no need of requesting audio focus, but I want to know when other apps do so I can update my status text accordingly.
Essentially, I believe that the function AudioManager.isMusicActive() will provide essentially exactly what I want to know, however since I am writing a service that will be always on I would like to avoid needing to poll that on a constant basis. I need the information in near real time, so it would essentially be a 1 second poll in perpetuity.
I'm looking for a way to detect when STREAM_MUSIC is being used by another app.
Some ways I have thought about doing it:
(1) Again, a perpetual poll using either Timer or Handler to constantly poll the isMusicActive() function. Not ideal from a battery or processor management perspective. I could use a flag variable in the UI Activity to control when the poll runs (it isn't really necessary when the UI isn't in the foreground, anyways), but I still think I'm using more processor/battery time than I'd need to.
(2) Listen for a broadcast of some kind, but none of the Android audio broadcasts seem to really fit the bill. (that I could find)
(3) I could, I suppose, request audio focus and just never play any audio and never give it up. Theoretically, since I am starting this in an always on service I believe that should allow my app to sit at the bottom of the LIFO audio focus stack and I would be notified via the AudioManager.OnAudioFocusChangeListener mechanism in basically the opposite way of its intended purpose (i.e. turn on my app when I lose audio focus and turn it off when I gain audio focus back). However, I'm not entirely sure how doing something like this would function in real-life usage. I feel like abusing the audio focus methodology for something like this could very easily result in negative user experiences in situations I haven't even thought of.
(4) Is there a way to use the AudioManager.OnAudioFocusChangeListener (or similar) without needing to request audio focus at all?
Are there any other ways I could go about doing this? Just a pointer in the right direction would be incredibly helpful!
I needed similar thing, so did a bit of research.
Unfortunately, there seems to be no other way to accomplish this except of requesting audio focus in your app.
Material for study:
Check Android source code in frameworks\base\media\java\android\media\ where you can find actual code for requestAudioFocus in MediaFocusControl class.
Other classes in this folder show how they send broadcast events for volume change, bluetooth on/off, etc, but no broadcast event at all related to audio enabled/disabled.
Another information on topic:
http://developer.android.com/training/managing-audio/audio-focus.html
http://developer.android.com/training/managing-audio/audio-output.html
Other than that, there doesn't seem to be any documented way to know when audio hardware starts/stops to play.
I trust that requesting audio focus without actually playing audio should not consume any battery. Only one ugly side effect is that this stops currently played audio.
I'm developing an application for android 2.3.3. It contains a few EditView's to show an information for an incoming call: country, current time, phone number... I know how to get and show that information. The problem I faced is that I don't know how to show my activity instead of the standard screen for incoming calls.
Now it shows the information after the incoming calls.
How to do it?
It's not possible. According to the PhoneApp the intent used to start the InCallScreen is bound to the phoneapp, you have no chance to intercept this. So the screen will be shown every time.
What you may try to do is to be notified by the TelephonyManager when the phone goes into the CALL_STATE_RINGING state and then paint your UI just over the InCallScreen. It may be possible to do so but you woudn't be able to offhook the call (unsure, but I don't think so) from your UI. Also the state is not set immediately when the InCallScreen pops up, it's delayed by some milliseconds.
Take a look at the questions about showing popups over the incoming call screen:
Popup over incoming-call screen
android incoming call screen
If it isn't enough to show a popup over the incoming call UI, then you could make your popup cover the whole screen to hide it. At that point you'll need a way to accept the incoming call without showing the default incoming call screen (which you are now covering). A quick search found this answer that suggests a workaround to accept the incoming call. I'm not sure offhand if there is an official API to do it.
It's impossible to remove the default UI of the incoming call in android, unless you modify the Android OS codings. But instead you can use your own custom UI activity over the default one. It's attained by using the Thread concept(to make the custom designed UI come-over the default one)!!