On Tue, May 28, 2013 12:54 pm, 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. >> >> 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. > FYI, I have had some contact from the android-x86 lead and he is very interested to bundle PA for that platform http://www.android-x86.org/ Arun, I am happy to coordinate this with you but you might also want to join the dev list too. David, just out of curiosity is Ubuntu interested in pushing the gstreamer packages to android-x86 too? I'm not sure how much crossover there is between the two projects. > 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? > -- Patrick Shirkey Boost Hardware Ltd
