Accessing already probed snd_card in kernel space

Accessing already probed snd_card in kernel space

[Shreshtha]

Hi, I am completely new to ALSA and ASoC so my question formation may seems
vague but I will try to be clear in objective.
How can I access already detected/populated sound card from inside the
kernel using standard ALSA kernel APIs?
Any mapping of kernel api for the following steps -

1) Find the right ALSA-card. (using snd_card_create)

2) Find the wanted ALSA-control for this card with snd_ctl_find_numid(...).

3) Modify the control

I want to configure the vibrator from kernel using the ALSA kernel APIs.

>From user space alsa_amixer -Dhw set/sset "vibra command" "..."
I want to do it from kernel space using ALSA apis.

BR
Mickey

Re: Accessing already probed snd_card in kernel space

[Lu Guanqun]

On Fri, Apr 15, 2011 at 01:46:41PM +0800, Shreshtha wrote:
> Hi, I am completely new to ALSA and ASoC so my question formation may seems
> vague but I will try to be clear in objective.
> How can I access already detected/populated sound card from inside the
> kernel using standard ALSA kernel APIs?
> Any mapping of kernel api for the following steps -
> 
> 1) Find the right ALSA-card. (using snd_card_create)
> 
> 2) Find the wanted ALSA-control for this card with snd_ctl_find_numid(...).
> 
> 3) Modify the control
> 
> I want to configure the vibrator from kernel using the ALSA kernel APIs.
> 
> From user space alsa_amixer -Dhw set/sset "vibra command" "..."
> I want to do it from kernel space using ALSA apis.

Why would you do that in kernel?

I don't think you should access it directly in subsystem other than
sound subsystem. Your scenario is very much like directly access an
opened file in kernel, which should be prohibited.

I'm afraid you can notify the userspace in kernel when you want to do
such kind of changes, and then let the userspace program issue the
command and change it for you. It's much clear.

> 
> BR
> Mickey
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
guanqun

Re: Accessing already probed snd_card in kernel space

[Clemens Ladisch]

Shreshtha wrote:
> How can I access already detected/populated sound card from inside the
> kernel using standard ALSA kernel APIs?

Why would you want to do this?  Why can't you do this from user space?

Anyway, there is no 'standard' ALSA kernel API.  You might have a look
at how the OSS emulation code accesses the ALSA devices.


Regards,
Clemens

Re: Accessing already probed snd_card in kernel space

[Shreshtha]

Thanks Lu and Clemens for reply.

Vibrator hardware is connected to D-Class amplifier of Audio block. Audio
block has its ASoC driver.
One way in Android is to use timed_output
("/sys/class/timed_output/vibrator/enable").
I wanted to access the alsa card, configure it and play vibrator from
"timed_output vibrator driver" in Kernel space.

But as you described that accessing from out side the sound subsystem is
prohibited in Kernel.
So only way remains is to access the sound card from user space using ALSA
lib APIs and replace current usage of sysfs for haptic feedback. Please
suggest if it is right direction.

On Fri, Apr 15, 2011 at 12:00 PM, Lu Guanqun <guanqun.lu@intel.com> wrote:

> On Fri, Apr 15, 2011 at 01:46:41PM +0800, Shreshtha wrote:
> > Hi, I am completely new to ALSA and ASoC so my question formation may
> seems
> > vague but I will try to be clear in objective.
> > How can I access already detected/populated sound card from inside the
> > kernel using standard ALSA kernel APIs?
> > Any mapping of kernel api for the following steps -
> >
> > 1) Find the right ALSA-card. (using snd_card_create)
> >
> > 2) Find the wanted ALSA-control for this card with
> snd_ctl_find_numid(...).
> >
> > 3) Modify the control
> >
> > I want to configure the vibrator from kernel using the ALSA kernel APIs.
> >
> > From user space alsa_amixer -Dhw set/sset "vibra command" "..."
> > I want to do it from kernel space using ALSA apis.
>
> Why would you do that in kernel?
>
> I don't think you should access it directly in subsystem other than
> sound subsystem. Your scenario is very much like directly access an
> opened file in kernel, which should be prohibited.
>
> I'm afraid you can notify the userspace in kernel when you want to do
> such kind of changes, and then let the userspace program issue the
> command and change it for you. It's much clear.
>
> >
> > BR
> > Mickey
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
> --
> guanqun
>



-- 
shreshthakumar@gmail.com

Re: Accessing already probed snd_card in kernel space

[Clemens Ladisch]

Shreshtha wrote:
> Vibrator hardware is connected to D-Class amplifier of Audio block.

Does this mean that you have to generate the vibration waveform as
sound data and write it to the sound device?  This would be rather
unwieldy in kernel space.  (Just accessing a mixer control would be
possible.)

> But as you described that accessing from out side the sound subsystem is
> prohibited in Kernel.

It's not prohibited, it's just not the way the API was designed.

> So only way remains is to access the sound card from user space using ALSA
> lib APIs and replace current usage of sysfs for haptic feedback. Please
> suggest if it is right direction.

Is the sysfs API a _required_ Android API, or would Android allow you
to write a user space driver?


Regards,
Clemens

Re: Accessing already probed snd_card in kernel space

[Shreshtha]

On Fri, Apr 15, 2011 at 1:27 PM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Shreshtha wrote:
> > Vibrator hardware is connected to D-Class amplifier of Audio block.
>
> Does this mean that you have to generate the vibration waveform as
> sound data and write it to the sound device?  This would be rather
> unwieldy in kernel space.  (Just accessing a mixer control would be
> possible.)
>
> [Shreshtha] Yes that is also a use case. But I require just to enable the
vibrator for x msec and turn it off.
This is for haptic feedback.
Please suggest how to "just accessing a mixer control" from kernel?


> > But as you described that accessing from out side the sound subsystem is
> > prohibited in Kernel.
>
> It's not prohibited, it's just not the way the API was designed.
>
> [Shreshtha] So I feel even if I use the ALSA API (or OSS emulation) in
timed_output vibrator and manage to turn on the vibrator, that will not be
accepted by kernel community.

> So only way remains is to access the sound card from user space using ALSA
> > lib APIs and replace current usage of sysfs for haptic feedback. Please
> > suggest if it is right direction.
>
> Is the sysfs API a _required_ Android API, or would Android allow you
> to write a user space driver?
>
> [Shreshtha]  I found this one way of implementation seen on other devices.
There can be other, and now I feel I require one.

>
> Regards,
> Clemens
>



-- 
shreshthakumar@gmail.com

Re: Accessing already probed snd_card in kernel space

[Lu Guanqun]

On Fri, Apr 15, 2011 at 04:27:08PM +0800, Shreshtha wrote:
> 
> 
> > So only way remains is to access the sound card from user space using ALSA
> > lib APIs and replace current usage of sysfs for haptic feedback. Please
> > suggest if it is right direction.
> 
> Is the sysfs API a _required_ Android API, or would Android allow you
> to write a user space driver?
> 
> [Shreshtha]  I found this one way of implementation seen on other devices. There can be other, and now I feel I require one.

You might use input subsystem to notify the userspace, just like jack's
implementation in sound subsystem.

> 
> Regards,
> Clemens
> 
> 
> 
> --
> shreshthakumar@gmail.com<mailto:shreshthakumar@gmail.com>

-- 
guanqun

Re: Accessing already probed snd_card in kernel space

[Shreshtha]

Sorry, I couldn't get your point of sending notification to userspace.

just describing my understanding, if we are in same page -
For example if user touches a phone button, android gets the notification
from touch driver and in its reaction it displays the button on screen and
also uses sysfs interface (one way of implementation) to make vibrator
vibrate (haptic feedback).
sysfs open/enable handled by timed_output vibrator driver, which internally
can enable/drive some vibrator via GPIO or Audio block etc.
Here my case is Audio block and directly accessing Audio block registers is
not suggested.
So ALSA API inside the kernel which comes to mind. But now I am not sure if
that is even possible and recommended.

So proper way I see is to remove sysfs interface and implement the glue
layer of android and kernel using ALSA lib API to configure the mixer.

BR
Shreshtha

On Fri, Apr 15, 2011 at 2:06 PM, Lu Guanqun <guanqun.lu@intel.com> wrote:

> On Fri, Apr 15, 2011 at 04:27:08PM +0800, Shreshtha wrote:
> >
> >
> > > So only way remains is to access the sound card from user space using
> ALSA
> > > lib APIs and replace current usage of sysfs for haptic feedback. Please
> > > suggest if it is right direction.
> >
> > Is the sysfs API a _required_ Android API, or would Android allow you
> > to write a user space driver?
> >
> > [Shreshtha]  I found this one way of implementation seen on other
> devices. There can be other, and now I feel I require one.
>
> You might use input subsystem to notify the userspace, just like jack's
> implementation in sound subsystem.
>
> >
> > Regards,
> > Clemens
> >
> >
> >
> > --
> > shreshthakumar@gmail.com<mailto:shreshthakumar@gmail.com>
>
> --
> guanqun
>



-- 
shreshthakumar@gmail.com

Re: Accessing already probed snd_card in kernel space

[Koul, Vinod]

On Fri, 2011-04-15 at 13:57 +0530, Shreshtha wrote:
> On Fri, Apr 15, 2011 at 1:27 PM, Clemens Ladisch <clemens@ladisch.de> wrote:
> 
> > Shreshtha wrote:
> > > Vibrator hardware is connected to D-Class amplifier of Audio block.
> >
> > Does this mean that you have to generate the vibration waveform as
> > sound data and write it to the sound device?  This would be rather
> > unwieldy in kernel space.  (Just accessing a mixer control would be
> > possible.)
> >
> > [Shreshtha] Yes that is also a use case. But I require just to enable the
> vibrator for x msec and turn it off.
> This is for haptic feedback.
> Please suggest how to "just accessing a mixer control" from kernel?
Sorry for late reply...been on a vacation

I have implemented a similar mechanism, all the vibrator controls are
exposed as mixer elements by the codec driver.
To turn on just treat the vibrator as input and connect them in
userspace to the output, that will power on this path and you cna get x
ms vibrations

HTH
-- 
~Vinod