[alsa-devel] Disabling DAPM from ASoC framework
Hi,
I'm a newbie to ALSA/ASoC framework. Lets say there is a requirement, where, the application (user space) takes the responsibility to switch ON/OFF the power components of the codec components (using ALSA Mixer Interface).
In this case, is there a standard way to disable DAPM from ASoC? One way I see (and found to be working) is setting num_dapm_widgets=0 and num_dapm_routes=0 before invoking snd_soc_register_codec()
Thanks in advance for your help.
Best Regards, San
1: don't call snd_soc_dapm_new_controls() snd_soc_dapm_add_routes() in your codec driver 2: don't set "static struct snd_soc_codec_driver{}" .dapm_widgets .dapm_routes
2014-04-21 15:40 GMT+08:00 Santhosh N M santo4ul@gmail.com:
Hi,
I'm a newbie to ALSA/ASoC framework. Lets say there is a requirement, where, the application (user space) takes the responsibility to switch ON/OFF the power components of the codec components (using ALSA Mixer Interface).
In this case, is there a standard way to disable DAPM from ASoC? One way I see (and found to be working) is setting num_dapm_widgets=0 and num_dapm_routes=0 before invoking snd_soc_register_codec()
Thanks in advance for your help.
Best Regards, San _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Thanks huhb04, for your quick response. It works!
This approach looks much cleaner than what I was originally trying.
Best Regards, San
On Mon, Apr 21, 2014 at 1:52 PM, 胡洪兵 huhb04@gmail.com wrote:
1: don't call snd_soc_dapm_new_controls() snd_soc_dapm_add_routes() in your codec driver 2: don't set "static struct snd_soc_codec_driver{}" .dapm_widgets .dapm_routes
2014-04-21 15:40 GMT+08:00 Santhosh N M santo4ul@gmail.com:
Hi,
I'm a newbie to ALSA/ASoC framework. Lets say there is a requirement, where, the application (user space) takes the responsibility to switch ON/OFF the power components of the codec components (using ALSA Mixer Interface).
In this case, is there a standard way to disable DAPM from ASoC? One way I see (and found to be working) is setting num_dapm_widgets=0 and num_dapm_routes=0 before invoking snd_soc_register_codec()
Thanks in advance for your help.
Best Regards, San _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Mon, Apr 21, 2014 at 01:10:42PM +0530, Santhosh N M wrote:
I'm a newbie to ALSA/ASoC framework. Lets say there is a requirement, where, the application (user space) takes the responsibility to switch ON/OFF the power components of the codec components (using ALSA Mixer Interface).
In this case, is there a standard way to disable DAPM from ASoC? One way I see (and found to be working) is setting num_dapm_widgets=0 and num_dapm_routes=0 before invoking snd_soc_register_codec()
This isn't supported, it's mandatory to have DAPM support in drivers - if there are no DAPM widgets it's likely things will break. Why do you not want to do power management?
Hi Mark,
Thanks for your email.
Why do you not want to do power management?
It is because of the following reasons,
1) Due the complication in hardware (where codec is inbuilt to the SoC) and the software architecture, we decided to leave all the AMPs, DIFFINs and SINGINs ON always. All the MUXs are pre-configured (in codec driver) to route audio to the right path. So there is no real need to switch OFF any of the power components on the device! 2) The device is AC powered and power consumption is not a problem here (unlike battery operated devices)
Currently I'm achieving this by (in snd_soc_codec_driver structure)
.dapm_widgets = NULL; .num_dapm_widgets = 0; .dapm_routes = NULL; .num_dapm_routes = 0;
Also, I'm not invoking any DAPM related functions (snd_soc_dapm_add_routes(), snd_soc_dapm_sync(), etc.)
This approach worked when I tested quickly. However, I'm slightly worried when you say " it's likely things will break". Not sure if there could lead to some memory leak in the long run.
Do you have any recommendation to achieve this in the right way?
Thank you.
Best Regards, San
On Tue, Apr 22, 2014 at 4:09 AM, Mark Brown broonie@kernel.org wrote:
On Mon, Apr 21, 2014 at 01:10:42PM +0530, Santhosh N M wrote:
I'm a newbie to ALSA/ASoC framework. Lets say there is a requirement, where, the application (user space) takes the responsibility to switch ON/OFF the power components of the codec components (using ALSA Mixer Interface).
In this case, is there a standard way to disable DAPM from ASoC? One
way
I see (and found to be working) is setting num_dapm_widgets=0 and num_dapm_routes=0 before invoking snd_soc_register_codec()
This isn't supported, it's mandatory to have DAPM support in drivers - if there are no DAPM widgets it's likely things will break. Why do you not want to do power management?
On Tue, Apr 22, 2014 at 10:17:35AM +0530, Santhosh N M wrote:
Why do you not want to do power management?
It is because of the following reasons,
- Due the complication in hardware (where codec is inbuilt to the SoC) and
the software architecture, we decided to leave all the AMPs, DIFFINs and SINGINs ON always. All the MUXs are pre-configured (in codec driver) to route audio to the right path. So there is no real need to switch OFF any of the power components on the device!
That doesn't sound like a generic upstreamable driver that'll work on other systems...
- The device is AC powered and power consumption is not a problem here
(unlike battery operated devices)
This isn't done purely for power reasons, it's also done so that an idle device doesn't end up playing the noise floor which generally is audible and so that changing use cases can be done without generating noise.
This approach worked when I tested quickly. However, I'm slightly worried when you say " it's likely things will break". Not sure if there could lead to some memory leak in the long run.
Not memory leaks particularly, but the framework does assume that DAPM is there and may fail to do things like start the audio streams. If it's holding together for you it'll probably not break but I'd expect you'll run into trouble if you try to move forward to a new kernel version, and possibly if you change what you're doing on your current one.
Do you have any recommendation to achieve this in the right way?
If you really want the audio stream up all the time I'd just play audio all the time from your sound server.
participants (3)
-
Mark Brown -
Santhosh N M -
胡洪兵