I've been looking around for a while but couldn't find much about this. I have an AudioComponentInstance that I use to continuously record the user while in-app. This doesn't get written to a file, but I do some light processing in a recording callback. This light processing is basically an offline, lightweight voice activity detection system on every 100ms of audio data.
So essentially what I have is like the Hey Siri feature. While in-app, the microphone is always on. It waits for the user to start talking, and once the lightweight recognizer detects speech, other stuff happens.
I know this can be very battery efficient because Hey Siri is a system-wide feature. But at the same time, I have no clear idea of the impact on battery life. I only have anecdotal data – for example, the Sleep Cycle app uses 30% of battery if your phone is not charging while you sleep. So in that case, 30% battery for 8 hours of mic use. But that might be high because they're constantly doing some sort of sleep processing?
Is there a way to use Instruments or something to do an isolated battery test, or someone who has a better understanding of the microphone's impact on battery life? Thanks!
In your case, using "Hey Siri" as a comparison is not accurate because this feature relies on a dedicated SoC, specifically to optimize power usage. In your scenario, you have no choice but to consume CPU resources which will result in a higher power draw.
While further testing would be required, my assumption is that your power usage will be no better than an app in idle state at best (YMMV based on what else your app is doing).
https://machinelearning.apple.com/2017/10/01/hey-siri.html
To avoid running the main processor all day just to listen for the
trigger phrase, the iPhone’s Always On Processor (AOP) (a small,
low-power auxiliary processor, that is, the embedded Motion
Coprocessor) has access to the microphone signal (on 6S and later). We
use a small proportion of the AOP’s limited processing power to run a
detector with a small version of the acoustic model (DNN).
The acoustic model it is referring to is the trigger phrase "Hey Siri", which it has been highly optimized to detect, again circling back to power and performance considerations.
Related
I was just monitoring my iOS game's energy usage and I see that the foreground app activity often goes as high as 126%. I am just wondering if this is something I should be concerned about? The energy usage shows a constant value of 1/20--- yet the time column is always "00:00 - 00:00", so I am a little confused about what that means.
Also, is there a way to disable bluetooth, gps in my app since those features are unused? I assume they would contribute to some sort of energy usage. Instruments shows no information other than state is "on" with a time of "00:00".
Based on the Apple docs: https://developer.apple.com/library/content/documentation/Performance/Conceptual/EnergyGuide-iOS/MonitorEnergyWithInstruments.html
The Energy Usage instrument indicates a level from 0 to 20, indicating
how much energy your app is using at any given time. These numbers are
subjective. If your app’s energy usage level is occasionally high, it
doesn’t necessarily mean that your app has a problem. Your app may
simply require more energy for some of the tasks it performs. For
example, it may use the GPS while performing complex network
operations. This is valid energy use. What you should look for are
spikes or areas of high energy use that are unexpected or that could
be performed at more optimal times.
I don't think I'd sweat what you are seeing too much. What is your FPS? Are you maintaining a 60 fps? Your main time is spent on your foreground app, so if you're looking to thin it down you should looking at what your CPU is doing. You an look at Time Profiler if you want to see if you can improve performance there.
That being said, I think users do realize battery life will suffer if you're playing a game. However, that comment should be tempered with the type of game. If you're doing Tic Tac Toe and you're sucking the life out of a battery, I think you'll raise some brows.
You don't have means (which won't get you rejected) to forcibly turn off things. And even if you could you also could end up with angry users too. Say you're using a bluetooth headset ... and you kill bluetooth?
Just make sure your game is fun and people will forgive you ;)
We are going to develop a Project on Sound Source Localization using Labview. Still We are on intial stage and going to perform all task on Software base with four mic connected with PC (For initial stage, later on going to develop using NI hardware if possible).
Initially we acquireing sound from 4 Different Microphones connected with computer through USB. Here all microhpones acquiring sound from single sound source with some delay(mili seconds) beacuse of their different position. But this Sound data acquired by USB are not able to write to sound card simulteneously. This data of sound acquire some hold time while writing to the sound card and we are getting some delay samples while synchronizaing these all sounds. Is there any idea to reduce this hold time of sounds that writes the data to the sound card?
Suppose hold time 10ms, want to reduce this to the micro seconds of nano seconds.
Reducing of the hold time as well as precise inter-channel synchronisation are not possible with LabVIEW running under Windows, and regular sound acquisition hardware. Internal software delays comparable with the time slice are to be expected (~10ms).
You need at least dedicated acquisition hardware (not a number of USB sound cards), and, if you would like to have precise synchronisation of your output with the input with minimum jitter, you need NI-FPGA. Giving these requirements, I would look at the R-series
I am trying to find Energy Usage for my iOS App using Instrument.
I got the statistics like Time, Total Activity, Foreground App Activity, Audio Processing and
Graphics in Percentage format. The sum of Foreground App Activity, Audio Processing and
Graphics is different from Total Activity !
But I am not understanding what are the meaning of these columns? Can anybody please explain me the meaning of these statistics and how to use this?
Latest Energy Diagnostics documentation says:
The Energy Usage instrument shows a level from 0 to 20, indicating how
much energy your app is using at a given time. These numbers are
subjective. If your app’s energy usage level is occasionally high, it
doesn’t necessarily mean that your app has a problem. Your app may
simply require more energy for some of the tasks it performs. For
example, it may use GPS while performing complex network operations.
This is valid energy use. What you should look for are spikes or areas
of high energy use that are unexpected or that could be performed at
more optimal times.
yes, sure there is difference. The best way to use it; do one at a time. observe each Activity Consumption and target optimizing that.
I'd like to load a small audio clip like a beep into memory, and schedule playback after x seconds with very low jitter. My application ideally gets less than +-1ms, but +-5ms could still be useful. The time is synchronized to a remote application without a microphone. My question is what kind of jitter can I expect from the audio APIs, and are they all equal in this regard?
I'm not familiar with the audio APIs, but from the latency discussions I've seen the number 5.8ms using remoteIO audio units. Does this mean +-3ms would be the best precision possible?
You would need to set this process as Real-Time to have a guarantee of low delay, otherwise you can get jitter in seconds because operating system can decide to make some background job.
Once you got it as real-time, you might archive lower delay.
Please check with Apple if you can make process real-time (with scheduling options). You might want to have extra permissions and kernel level support in your app to do it properly, that you can have guaranteed 1ms delay for audio app.
I'm looking to do some high precision core motion reading (>=100Hz if possible) and motion analysis on the iPhone 4+ which will run continuously for the duration of the main part of the app. It's imperative that the motion response and the signals that the analysis code sends out are as free from lag as possible.
My original plan was to launch a dedicated NSThread based on the code in the metronome project as referenced here: Accurate timing in iOS, along with a protocol for motion analysers to link in and use the thread. I'm wondering whether GCD or NSOperation queues might be better?
My impression after copious reading is that they are designed to handle a quantity of discrete, one-off operations rather than a small number of operations performed over and over again on a regular interval and that using them every millisecond or so might inadvertently create a lot of thread creation/destruction overhead. Does anyone have any experience here?
I'm also wondering about the performance implications of an endless while loop in a thread (such as in the code in the above link). Does anyone know more about how things work under the hood with threads? I know that iPhone4 (and under) are single core processors and use some sort of intelligent multitasking (pre-emptive?) which switches threads based on various timing and I/O demands to create the effect of parallelism...
If you have a thread that has a simple "while" loop running endlessly but only doing any additional work every millisecond or so, does the processor's switching algorithm consider the endless loop a "high demand" on resources thus hogging them from other threads or will it be smart enough to allocate resources more heavily towards other threads in the "downtime" between additional code execution?
Thanks in advance for the help and expertise...
IMO the bottleneck are rather the sensors. The actual update frequency is most often not equal to what you have specified. See update frequency set for deviceMotionUpdateInterval it's the actual frequency? and Actual frequency of device motion updates lower than expected, but scales up with setting
Some time ago I made a couple of measurements using Core Motion and the raw sensor data as well. I needed a high update rate too because I was doing a Simpson integration and thus wnated to minimise errors. It turned out that the real frequency is always lower and that there is limit at about 80 Hz. It was an iPhone 4 running iOS 4. But as long as you don't need this for scientific purposes in most cases 60-70 Hz should fit your needs anyway.