Android Kit Kat Openly Preaching for DSP offloading

In fact KitKat advocates low-power always-on functionality, and this is essential for contextual-awareness. Always-on functionality is saving battery life, which seems to be weird at first: if your phone is always-on you would expect it to consume much power… But always-on goes together with screen-off (the screen is a high source of power consumption) and means that the Application Processor is off or on idle state, but real time location tracking and contextual awareness functions run in the background, thanks to DSP offloading. If we compare the power consumption linked with three different architectures:

• Voice activation on ARM Application Processor takes about 20 mA
• Using a dedicated chip for handling always-on voice processing, like MOTO X using TI C55, the consumption goes down to 4.5 mA, which is already better, but not as good as when doing:
• Voice activation on CEVA TL410, the Teak Lite DSP core consuming less than 2 mA

CEVA has developed Android Multimedia Framework (AMF), and we have described in this blog how AMF can be useful to minimize power consumption in smartphones, simply by helping the OS to be aware that a DSP core, even deeply embedded, can be available to run certain tasks. In this case, these tasks are screen-off functionalities, including voice-trigger, audio playback, and sensor-fusion in general. Being able to run always-on functionality at the lowest possible power, in fact without involving the AP as we have seen when comparing the power consumption figures, is an essential condition to keep battery life as long as possible.

We all love listening to music on our phones. In fact, listening to music, audiobooks, or podcasts regularly on our smartphones is probably one of the few things we all really share in terms of our usage patterns. The problem with listening to audio for extended periods, though, is that it can really put the hammer down on your battery life. Google has introduced audio tunneling to DSP in Android 4.4. The premise is simple – instead of using the application processor to decode audio or respond to audio output requests, this responsibility is offloaded to the onboard DSP (digital signal processor). The DSP is much more efficient at such tasks than the CPU, and as such, Google estimates that the amount of power used playing back audio on your phone could decrease in excess of 50%!

AMF is a system level software solution and allows offloading of multimedia tasks from CPU/GPU to most efficient application-specific DSP platforms. When running Android OS, you need either to develop such a solution by yourself, either to benefit from a ready to use framework, allowing using deeply embedded programmable hardware engines, and software modules optimized for them. Due to its OS agnostic standard API, CEVA’s AMF would comply with any Android endorsed mechanism for multimedia offloading (e.g. KLP).

In summary, AMF features:

• AMF provides a seamless method for Android programmers to access Multimedia DSPs (audio, and also imaging) in the AP chip or CODEC chip, using high-level language or API, there is no need to directly program the DSP,
• AMF enables computing intensive multimedia tasks execution on “deeply-embedded” DSPs, resulting in lower power compared to same tasks on main CPU: as we have seen when comparing the power consumption figures, AMF allows down to 8x lower power for audio/voice applications
• AMF uses standard API and includes HAL drivers, Host-DSP communication modules, RTOS, and debug capability, offering a full reference design.

We can see on the right side of the above picture an AMF based architecture where the API run on the CPU, within the Stagefright Framework, and the SW run on DSP, when the mobile device is normally on. To run Always-on functionality, only the yellowed bottom right tasks essentials for contextual-awareness could run on the Teak Lite 410 DSP core, saving battery life, which is good for your smartphone, and for your end-user experience.

Eric Esteve from IPNEST –

More Articles by Eric Esteve …..

lang: en_US