ALSA's jack reporting framework map to Android framework

ALSA's jack reporting framework map to Android framework

[Harsha, Priya]

Hi all,

The ALSA's jack reporting framework reports jacks at /dev/input/eventx. But the Android framework expects the jack reporting to be done in /sys/.../switch/h2w.

Any suggestions as to how  the ALSA's jack reporting framework to Android framework? Are there any audio  drivers that have mapped this? Any kind of input would be really helpful

Thanks,
Harsha

Re: ALSA's jack reporting framework map to Android framework

[Mark Brown]

On Sat, Jun 12, 2010 at 09:28:34AM +0530, Harsha, Priya wrote:

Please fix your MUA to word wrap your messages, it makes them more
legible and easier to reply to.

> The ALSA's jack reporting framework reports jacks at
> /dev/input/eventx. But the Android framework expects the jack reporting
> to be done in /sys/.../switch/h2w.

That ... is simply 'class' - the Android kernel includes a new sysfs
class for switches, CCing in Mike Lockwood who wrote it in case he's got
any input from the Android side.

> Any suggestions as to how  the ALSA's jack reporting framework to
> Android framework? Are there any audio  drivers that have mapped this?

The obvious thing to do here seems to be to update the Android framework
to be able to use the standard kernel interfaces.  I obviously can't
speak for Google but it seems like the sort of patch they'd be willing
to accept, especially if you retain the ability to use the non-standard
extensions that are currently being used.

I guess an alternative would be to have the Android kernels add an
adaptor in the input subsystem (for various reasons not all jack sense
goes through ALSA) so that input subsystem switches get represented via
the Android switch ABI, though that would increase the amount of out of
tree code that needs to be carried and so seems like the wrong direction
to be heading.

Re: ALSA's jack reporting framework map to Android framework

[Mark Brown]

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.

Re: ALSA's jack reporting framework map to Android framework

[Harsha, Priya]

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.