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.