[alsa-devel] ASoC: Machine Driver Interaction with Codec Drivers
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
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
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
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.
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
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
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
participants (4)
-
Jeremy McDermond -
Lars-Peter Clausen -
Takashi Iwai -
Vinod Koul