Home › Forums › OpenEars plugins › Battery use is more than 40% in last 24 hours
- This topic has 6 replies, 2 voices, and was last updated 8 years, 4 months ago by Halle Winkler.
January 30, 2015 at 4:46 am #1024632
I were doing some long running testing with my app using OpenEars + Rejecto + RapidEars. My app is always staying in the background, using RapidEars to listen to some key words and respond text to speech correspondingly. I have noticed that the battery use is very high even though my app is just in the background. In last tests, it is more than 40% in last 24 hours based on what my iPhone shows.
Your documentation claims 1% CPU use so I was expecting also a single digit battery use. Is there anyway I can tune OpenEars to reduce its battery use?January 30, 2015 at 9:38 am #1024634
A few things: the documentation cites 2% usage on current devices (meaning older devices can use a bit more), not 1%, and also clarifies that this is only for periods of time in which no recognition is being performed or other tasks being performed by the app. Even so, 2% CPU usage for 24 hours straight will use up plenty of battery in a handheld device. 40% doesn’t sound unusual to me for an app which is providing audio services, including powering the mic, for 24 hours (my phone will have an empty battery if it backgrounds any app with an actual task for 24 hours).
However, beyond that, recognition will always result in a CPU spike, including recognition of noise which isn’t returned as a hypothesis. RapidEars uses more CPU while speech or sounds detected as speech are in progress versus stock OpenEars because it performs realtime recognition, so I’m actually pleasantly surprised to hear that you can run RapidEars continuously for 24 hours and still have 60% of your battery available.
You can reduce RapidEars’ CPU overhead by checking out its CPU-related properties in its header, and my guess is that different vadThreshold settings will also tend to affect battery usage – this should be tested in your app.
even though my app is just in the background
If it is being asked to listen for speech all the time when it is in the background, it should be expected to have the identical power usage profile as listening to speech all the time in the foreground. Background tasks save power by not having UIs to render but OpenEars doesn’t provide any UI so it will do the same things in the background as the foreground.January 31, 2015 at 3:48 pm #1024657
Halle, I meant 40% of battery used by all apps. With my app running, the battery will not last 24 hours. It is almost completely drained in the late afternoon.
I will try to tune vadThreshold.January 31, 2015 at 4:32 pm #1024658
I guess I don’t have any info yet about what you are seeing. How long did you run realtime speech recognition in the background for, and what was the battery at when you started, and what was it at when you stopped, and what tasks were the other apps that were running performing? Was there environmental noise that would prompt recognition to be performed or was it an extremely quiet environment?
If I have Google Maps in the background my phone lasts about 3 hours because it is working continuously, if it’s Mail.app and Twitter it has very little effect because they are just making occasional network calls. Continuous realtime speech recognition with a latency of a small fraction of a second which is run nonstop for many hours is going to have a power profile which resembles Google Maps more closely than it resembles than Mail.app.
If being able to run for a day is the primary design consideration it will be more productive to use stock OpenEars and perform pause-based recognition rather doing realtime recognition on all speech (and speech-volume sounds) as they are being uttered.
From the RapidEars documentation:
“If your application has a need for speed and you are shipping for devices that can support more CPU overhead”
Although RapidEars 2.x now uses less than half the CPU time that RapidEars 1.x used to, CPU overhead remains a design consideration in realtime recognition, which is why the RapidEars API gives access to CPU overhead settings.
I will try to tune vadThreshold.
Have you set setLatencyTuning: to 1?January 31, 2015 at 5:58 pm #1024660
Actually, I was not able to find vadThreshold. And how to set setLatencyTunning? Do you have a document about the parameters?January 31, 2015 at 6:16 pm #1024661
OK, I think I found where these settings are.
[[OEPocketsphinxController sharedInstance] setVadThreshold:0.5];
[[OEPocketsphinxController sharedInstance] setLatencyTuning: 1];
And this is what I see at the header file.
/**Speech/Silence threshhold setting. You may not need to make any changes to this, however, if you are experiencing quiet background noises triggering speech recognition, you can raise this to a value from 2-5 to 3.5 for the English acoustic model, and between 3.0 and 4.5 for the Spanish acoustic model. If you are experiencing too many words being ignored you can reduce this. The maximum value is 5.0 and the minimum is .5. For the English model, values less than 1.5 or more than 3.5 are likely to lead to poor results. For the Spanish model, higher values can be used. Please test any changes here carefully to see what effect they have on your user experience.*/
@property (nonatomic, assign) float vadThreshold;
I guess I will try to set it to 3.5?January 31, 2015 at 6:56 pm #1024666
Yes, set vadThreshold higher than the default, not lower, so it will perform recognition on fewer non-speech noises. It’s a good idea to test this at different settings to find the right level. If it was set to .5 instead of the default of 2.0 that will be the primary cause of CPU overuse since that will cause it to perform recognition on everything.
Latency tuning is even more important since it is expressly designed for reducing RapidEars’ CPU usage across the board. Take a look at RapidEars’ documentation for information about its properties – it’s in the header and PDF and on politepix.com/rapidears.
- You must be logged in to reply to this topic.