ASoC: Machine Driver Interaction with Codec Drivers

ASoC: Machine Driver Interaction with Codec Drivers

[Jeremy McDermond]

I apologize in advance for the probably idiotic question.

I’m working with writing a machine driver for our product and dealing with some potential user interface issues surrounding the number of controls being presented by the codec driver in the mixer.

Is there a way to “hard-wire” kcontrols in the codec from the machine driver and hide them in the mixer?  For example, our hardware doesn’t wire the IN2_L and IN2_R pins to anywhere, so the codec controls that determine their connections into the input mixer do nothing on our hardware and I’d like to hide them from the user in the mixer.

Am I missing something or is there just no way to get there from here?

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@xenotropic.com




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

Re: ASoC: Machine Driver Interaction with Codec Drivers

[Lars-Peter Clausen]

Hi,

No this is currently not really supported. There were some ideas for this a
long long time ago, but it never got implemented. And today basically
everybody takes care of hiding the controls from userspace.

That does not mean it does not make sense to have such a feature, but it
needs somebody with a motivation to implement it.

- Lars

On 06/08/2016 05:13 AM, Jeremy McDermond wrote:
> I apologize in advance for the probably idiotic question.
> 
> I’m working with writing a machine driver for our product and dealing with some potential user interface issues surrounding the number of controls being presented by the codec driver in the mixer.
> 
> Is there a way to “hard-wire” kcontrols in the codec from the machine driver and hide them in the mixer?  For example, our hardware doesn’t wire the IN2_L and IN2_R pins to anywhere, so the codec controls that determine their connections into the input mixer do nothing on our hardware and I’d like to hide them from the user in the mixer.
> 
> Am I missing something or is there just no way to get there from here?
> 
> --
> Jeremy McDermond (NH6Z)
> Xenotropic Systems
> mcdermj@xenotropic.com
> 
> 
> 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

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

Re: ASoC: Machine Driver Interaction with Codec Drivers

[Takashi Iwai]

On Wed, 08 Jun 2016 21:14:01 +0200,
Lars-Peter Clausen wrote:
> 
> Hi,
> 
> No this is currently not really supported. There were some ideas for this a
> long long time ago, but it never got implemented. And today basically
> everybody takes care of hiding the controls from userspace.
> 
> That does not mean it does not make sense to have such a feature, but it
> needs somebody with a motivation to implement it.

The devils live in details.  Actually a primary question is in which
level we should cover it.  For example, can we disable DAPM pins from
the machine driver?  This will reduce not only kctls but DAPM paths.
Or should we mark kctls just as invisible?  Or, would it be suitable
rather to hide such a thing in user-space?

More crazy ideas welcome.


Takashi


> 
> - Lars
> 
> On 06/08/2016 05:13 AM, Jeremy McDermond wrote:
> > I apologize in advance for the probably idiotic question.
> > 
> > I’m working with writing a machine driver for our product and dealing with some potential user interface issues surrounding the number of controls being presented by the codec driver in the mixer.
> > 
> > Is there a way to “hard-wire” kcontrols in the codec from the machine driver and hide them in the mixer?  For example, our hardware doesn’t wire the IN2_L and IN2_R pins to anywhere, so the codec controls that determine their connections into the input mixer do nothing on our hardware and I’d like to hide them from the user in the mixer.
> > 
> > Am I missing something or is there just no way to get there from here?
> > 
> > --
> > Jeremy McDermond (NH6Z)
> > Xenotropic Systems
> > mcdermj@xenotropic.com
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ASoC: Machine Driver Interaction with Codec Drivers

[Lars-Peter Clausen]

On 06/09/2016 11:49 AM, Takashi Iwai wrote:
> On Wed, 08 Jun 2016 21:14:01 +0200,
> Lars-Peter Clausen wrote:
>>
>> Hi,
>>
>> No this is currently not really supported. There were some ideas for this a
>> long long time ago, but it never got implemented. And today basically
>> everybody takes care of hiding the controls from userspace.
>>
>> That does not mean it does not make sense to have such a feature, but it
>> needs somebody with a motivation to implement it.
> 
> The devils live in details.  Actually a primary question is in which
> level we should cover it.  For example, can we disable DAPM pins from
> the machine driver?  This will reduce not only kctls but DAPM paths.
> Or should we mark kctls just as invisible?  Or, would it be suitable
> rather to hide such a thing in user-space?

For DAPM we already do this. Even automatically the DAPM core is capable of
figuring out which paths are unused and will never be powered-up. The path
will still exist in the graph but it will be ignored for all operations and
not significantly affect performance.

And I think the idea back then was to track which controls are on which
paths and if it is on a non-connected path disable the control. What's a bit
tricky is if you have a mixer or mux and only some of the output/input paths
are not connected. Also for most controls we do not have the information
where they are placed within the graph.

Re: ASoC: Machine Driver Interaction with Codec Drivers

[Vinod Koul]

On Thu, Jun 09, 2016 at 11:49:28AM +0200, Takashi Iwai wrote:
> On Wed, 08 Jun 2016 21:14:01 +0200,
> Lars-Peter Clausen wrote:
> > 
> > Hi,
> > 
> > No this is currently not really supported. There were some ideas for this a
> > long long time ago, but it never got implemented. And today basically
> > everybody takes care of hiding the controls from userspace.
> > 
> > That does not mean it does not make sense to have such a feature, but it
> > needs somebody with a motivation to implement it.
> 
> The devils live in details.  Actually a primary question is in which
> level we should cover it.  For example, can we disable DAPM pins from
> the machine driver?  This will reduce not only kctls but DAPM paths.
> Or should we mark kctls just as invisible?  Or, would it be suitable
> rather to hide such a thing in user-space?

Today codecs give DAPM graph but that is not linked in kctls. If we do that,
then DAPM can hide un-connected graphs!

For SKL DSP modules, we have modelled kctls in DAPM using PGA as we have to
enable/disable modules, so for DSP at least we can do this :)

So simpler might be to add dummy widgets to kctls by drivers and then hide.
Or we can have extended graph which has "extra" graph which show kctls to
graph links.

Thanks
-- 
~Vinod

Re: ASoC: Machine Driver Interaction with Codec Drivers

[Jeremy McDermond]

Thanks to everyone for their responses on this.  I’m glad I wasn’t missing  
anything stupid.

Lars-Peter Clausen <lars@metafoo.de> wrote:

> And today basically
> everybody takes care of hiding the controls from userspace.

What are people’s strategies for doing this from userspace?  I’ve ingested  
all the docs I could about .asoundrc but wasn’t seeing anything obvious  
where I could hard wire controls.  I could populate alsa.state, but that’s  
a really ugly solution.

> - Lars

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@xenotropic.com




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

Re: ASoC: Machine Driver Interaction with Codec Drivers

[Lars-Peter Clausen]

On 06/13/2016 11:37 PM, Jeremy McDermond wrote:
> Thanks to everyone for their responses on this.  I’m glad I wasn’t missing
> anything stupid.
> 
> Lars-Peter Clausen <lars@metafoo.de> wrote:
> 
>> And today basically
>> everybody takes care of hiding the controls from userspace.
> 
> What are people’s strategies for doing this from userspace?  I’ve ingested
> all the docs I could about .asoundrc but wasn’t seeing anything obvious
> where I could hard wire controls.  I could populate alsa.state, but that’s a
> really ugly solution.

There are different solutions used by different projects.

Some just hardcode the list of exposed controls in their sound daemon
(although that's not something I'd recommend).

There is ALSA UCM
(http://www.alsa-project.org/main/index.php/Use_Case_Manager
http://www.slimlogic.co.uk/2009/02/alsa-use-case-manager/) which allows you
to define groups of control settings as profiles and also define which
individual controls to expose.

And Android has something similar to UCM, but I can't remember the name
right now.

- Lars

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