PulseAudio Ported To Android, Compared To AudioFlinger
A developer at Collabora has brought PulseAudio to Google's Android operating system. In the process of this port he has closely compared the performance and features of the once-notorious PulseAudio stack to that of Google's AudioFlinger.
AudioFlinger is Google's audio stack equivalent to PulseAudio. AudioFlinger provides a single output path for PCM, a software mixer for various playback stream types, playback stream resampling, and a single input capture path. Collabora decided it would be interesting -- and of potential interest to their customers -- to bring the PulseAudio stack over to Android. Among the desired PulseAudio features mentioned to have on Android was its modular framework, power saving features, and flexible routing, among other traits.
Assigned to this work at Collabora was Arun Raghavan. A Galaxy Nexus running Android 4.0 "Ice Cream Sandwich" was used in the PulseAudio porting process. The Nexus has an OMAP4 processor with a chip that has "pretty good support for running stock Linux", making it a good candidate for the PulseAudio work.
Raghavan integrated PulseAudio into the base Android system (rather than an Android NDK), brought the various PulseAudio dependencies over to Android, and other various work was needed.
On his blog, Raghavan extensively details the PulseAudio porting process. He also shares some of his findings. This includes PulseAudio's CPU usage is generally more favorable than AudioFlinger, the memory consumption between the two audio stacks is comparable but slightly more favorable to AudioFlinger, and the power consumption was definitely in favor of PulseAudio. The PulseAudio power savings features were working much better than Google's audio implementation for Android. In his blog post he also compares the features of the two Linux audio stacks.
Arun Raghavan will be upstreaming the work he did for PulseAudio on Android. He also plans to write a wrapper on top of PulseAudio that would expose AudioFlinger APIs for audio and policy so that PulseAudio could serve as a drop-in replacement to the default Android audio stack. There's also talk of further performance improvements for PulseAudio by taking advantage of some Android-specific features like Binder and ashmem.
What's next to come to Android? Perhaps systemd?
AudioFlinger is Google's audio stack equivalent to PulseAudio. AudioFlinger provides a single output path for PCM, a software mixer for various playback stream types, playback stream resampling, and a single input capture path. Collabora decided it would be interesting -- and of potential interest to their customers -- to bring the PulseAudio stack over to Android. Among the desired PulseAudio features mentioned to have on Android was its modular framework, power saving features, and flexible routing, among other traits.
Assigned to this work at Collabora was Arun Raghavan. A Galaxy Nexus running Android 4.0 "Ice Cream Sandwich" was used in the PulseAudio porting process. The Nexus has an OMAP4 processor with a chip that has "pretty good support for running stock Linux", making it a good candidate for the PulseAudio work.
Raghavan integrated PulseAudio into the base Android system (rather than an Android NDK), brought the various PulseAudio dependencies over to Android, and other various work was needed.
On his blog, Raghavan extensively details the PulseAudio porting process. He also shares some of his findings. This includes PulseAudio's CPU usage is generally more favorable than AudioFlinger, the memory consumption between the two audio stacks is comparable but slightly more favorable to AudioFlinger, and the power consumption was definitely in favor of PulseAudio. The PulseAudio power savings features were working much better than Google's audio implementation for Android. In his blog post he also compares the features of the two Linux audio stacks.
Arun Raghavan will be upstreaming the work he did for PulseAudio on Android. He also plans to write a wrapper on top of PulseAudio that would expose AudioFlinger APIs for audio and policy so that PulseAudio could serve as a drop-in replacement to the default Android audio stack. There's also talk of further performance improvements for PulseAudio by taking advantage of some Android-specific features like Binder and ashmem.
What's next to come to Android? Perhaps systemd?
38 Comments