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) > a; > else > b; > > ...to use function pointers, instead of ending up like: > > if (use_androidHAL) > c; > else if (use_ucm) > a; > else > b; 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. https://launchpad.net/~diwic
