On 05/28/2013 04:54 AM, Arun Raghavan wrote: > 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. To be more correct, this probably should have been "Ubuntu Touch" or "phablet". >> 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. That's a fair point. However, the HAL might do more than what is expressed by the XML config, e g, on the machine I'm targeting first (Nexus 7), what mic is being used is depending on how you currently hold the device (portrait or landscape). Now, using the wrong mic is probably not the end of the world, but this is just an example of the strange things that can happen inside the HAL that we have a hard time expressing through UCM/XML. As for using UCM, for me its PulseAudio implementation is still missing two killer features: HW volume/gain control, and jack detection. And, there is no official UCM documentation, so it's not possible to implement it either. There seem to be no initiative from the UCM side to improve this, which makes me wonder if anybody's actually using UCM in PulseAudio at all, in practice? (And add to that that Luke disabled UCM in Ubuntu because it regressed some machine he had) > 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. That's a very good point. The entire of PulseAudio should be LGPL, so the question is if there are GPL libraries that we link to. That could potentially be a problem if combined with binary blob HALs. It is also possible that it is not a problem, e g, if the HAL counts as a "system library", then *maybe* it's possible to link them anyway. I'm not sure. However, Canonical is targeting Nexus devices initially, which are all open source AFAIK. >> - 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. From what I can understand, this is the standard jack-detection mechanism on Android. > Anyway, we could shovel this into a separate module. Or at least a separate file. >> 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. I have not looked into it. From what I've been told, it's currently using AudioFlinger. This could/should be moved over to use HAL too. >> 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? > I'll do my best to keep existing files clean, naturally. Since we already have two mixer interfaces (UCM and the standard one) and I'm about to add a third (Android HAL), maybe we should try refactor things a little from if (use_ucm) a; else b; ...to use function pointers, instead of ending up like: if (use_androidHAL) c; else if (use_ucm) a; else b; -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
