[pulseaudio-discuss] PulseAudio on Android kernel, for Ubuntu phone
david.henningsson at canonical.com
Tue May 28 06:14:29 PDT 2013
On 05/28/2013 08:39 AM, David Henningsson wrote:
> On 05/28/2013 04:54 AM, Arun Raghavan wrote:
>> On Mon, 2013-05-27 at 20:57 +0200, David Henningsson wrote:
>>> 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)
> ...to use function pointers, instead of ending up like:
> if (use_androidHAL)
> else if (use_ucm)
Looking at this a little bit closer, I think it makes sense to make a
new card module, say module-android-card. Most of the stuff in
module-alsa-card are about ports, jacks, or profile probing. I probably
don't want any of that: the jack and ports are android specific, and
I'll happily just setup a simple profile to speed up booting.
Module-android-card would then set up its own mixer and jack detection,
and then call pa_alsa_(sink|source)_new as necessary.
Then I won't need to touch module-alsa-card.c at all, and the only
callbacks from alsa-(sink|source).c would be for getting/setting volume,
and possibly port.
I'm not really sure how udev will work on Ubuntu Touch, so not sure how
these modules will be loaded, and how hotplug will work for other cards.
David Henningsson, Canonical Ltd.
More information about the pulseaudio-discuss