Hi Mike,
Can you please CC your media team and so that we can discuss what is the right thing to do? Can we do a Android patch on the Android Framework to support ALSA's jack sensing? Is there any such effort already in progress from your media team? Looks like modifying our audio drivers to support Android Framework is not recommended by the community.
Thanks, Harsha
-----Original Message----- From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com] Sent: Sunday, June 13, 2010 3:47 PM To: Mike Lockwood; swetland@android.com Cc: Harsha, Priya; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] ALSA's jack reporting framework map to Android framework
On 12 Jun 2010, at 23:36, Mike Lockwood wrote:
There is no requirement to use the switch driver for the headset detect. At the time we did this we couldn't find an existing standard and we had already written the switch driver for something else, so it was an easy solution at the time. But if there is something better available now I don't see any reason not to use it.
In situations like this I'd always recommend discussing upstream - there may be something you've missed, or if there isn't then it means whatever you come up with can be adopted as a standard by everyone.
I don't know what the current thinking is about ALSA and android - someone on our media team would need to address that part of the thread. But if using ALSA requires GPL/LGPL code in userspace that would probably be a deal breaker right there.
Obviously there's already the option of using ALSA with the regular libraries (which are LGPLed) in Android which a bunch of vendors are using already - there's existing drivers for a range of CPUs and CODECs and many vendors are already shipping other Linux based OSs on their devices outside of Android which use things like the standard audio stack and so don't have a problem with LGPL in userspace.
Discussions with Brian Swetland (CCed in so he can correct me if I'm off base here) suggested that a direct to kernel option bypassing the standard libraries might be developed under a MITish license to provide as a default. This is obviously much less work than developing an entirely new audio stack would be, and unless plugins are in use the userspace portion is very thin.