[pulseaudio-discuss] PulseAudio on Android kernel, for Ubuntu phone

[Arun Raghavan]

On Mon, 2013-05-27 at 20:57 +0200, David Henningsson wrote:
> Well, as some of you already know, Canonical is currently working on an 
> Ubuntu phone product. Part of that is a well working audio stack.
> 
> In short, we're trying to build something where we can run as much of 
> standard Ubuntu as possible and as little of Android as possible, 
> without having to rewrite a lot of hardware specific stuff. That's at 
> least how I understand it. :-)
> 
> So, my plan is to start building something really soon. My draft plan 
> looks like:
> 
>   - For PCM streaming, I'll try to use native ALSA, i e, PulseAudio, 
> alsa-lib, kernel, just as on the desktop. This is for best performance, 
> and also because it's the nicest thing to do for non-PA sound servers 
> and applications (e g JACK).

Yep.

>   - For setting up the mixer, I'll try to talk to the Android HAL layer. 
> Mixer controls vary a lot between hardware, so making a bridge to 
> Android here would likely save us work in the long run. (This is the 
> most uncertain part.)

IMO, this is good for short-term porting effort, but not that great in
the longer term. The Android HAL is an abstraction on top of another
abstraction (UCM/XML config). To my mind, it makes more sense to use UCM
here. Or if the UCM folks prefer the newer XML format, we could look at
that as well.

However, since part of your goal is to have PA usable on devices without
a large porting effort, maybe having this option isn't bad. My main
worry is code clutter.

Just as a thought, do you know if we're clear, license-wise, to load
binary blob HALs? Particularly the ones that aren't
tinyalsa/tinyhal-based.

>   - For jack detection, in Android this is done through sysfs, and not 
> through the Android HAL. Thus I'll need to write code in PulseAudio to 
> listen to these uevents/sysfs changes.

It annoys me that we can't use more standard jack-detection mechanisms.
Anyway, we could shovel this into a separate module.

> So, I'm mostly posting this to see if you have better ideas, if there 
> are things I should think about before or during the implementation of 
> this code, if somebody has code that already does this hidden in his/her 
> closet, etc.

Have you had any thoughts on how to do support for voice calls? My PA
for Android trees have a working implementation for the Galaxy Nexus,
but I've not yet had the time to look at how things are done on other
phones.

> Also, I'm guessing that there wouldn't be any larger objections for 
> upstreaming this either - after all, if we are open to supporting 
> everything from Solaris to Win32, an Linux/Android hybrid should be okay 
> too, right? :-)

Broadly speaking, this should all be good. I guess my only worry as I
mentioned before is peppering Android-specific code in the ALSA modules,
particular mixer-related bits. Do you think that will be necessary, or
will we be able to cleanly split that off into separate files?

Cheers,
Arun