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?