[alsa-devel] get rid of controls with snd_ctl_remove
Hi there!
Please be patient with me, I am quite inexperienced with alsa programming, so this might be a dumb question:
We have a WM8750 working in our PDA, the codec is working so far but I want to remove some of the control since they aren't needed.
Instead of copying the wm8750.c file and adjusting it, I want to write another module which basically get rid of those controls, something like:
[...]
static const char* unused_controls[] = {"AAAA", "BBBB,"CCCC"};
struct snd_kcontrol *ctl;
list_for_each_entry(ctl, &card->controls, list) for(i=0; i < ARRAY_SIZE(unused_controls); i++) if (!strcmp(unused_controls[i],ctl->id.name)) { down_write(&card->controls_rwsem); snd_ctl_remove(card,ctl); up_write(&card->controls_rwsem); break; }
unfortunatly this doesn't work (module segfaults...."of course" you will say *g*)
My question: is it possible at all and I am just not deep nuff in understanding the sound system or do I have to adjust the original code?
Thx
Harry
At Fri, 29 Aug 2008 14:54:42 +0200, Harald Radke wrote:
Hi there!
Please be patient with me, I am quite inexperienced with alsa programming, so this might be a dumb question:
We have a WM8750 working in our PDA, the codec is working so far but I want to remove some of the control since they aren't needed.
Instead of copying the wm8750.c file and adjusting it, I want to write another module which basically get rid of those controls, something like:
[...]
static const char* unused_controls[] = {"AAAA", "BBBB,"CCCC"};
struct snd_kcontrol *ctl; list_for_each_entry(ctl, &card->controls, list)
You can't use list_for_each_entry() together with removal. Use list_for_each_entry_safe() for such a purpose.
But...
for(i=0; i < ARRAY_SIZE(unused_controls); i++) if (!strcmp(unused_controls[i],ctl->id.name)) { down_write(&card->controls_rwsem); snd_ctl_remove(card,ctl); up_write(&card->controls_rwsem); break; }
It'd be easier like the following:
for (i = 0; i < ARRAY_SIZE(unused_controls); i++) { struct snd_ctl_elem_id id; memset(&id, 0, sizeof(id)); strcpy(id.name, unused_controls[i]); id.iface = SNDRV_CTL_ELEM_IFACE_MIXER; snd_ctl_remove_id(card, &id); }
Takashi
On Fri, 2008-08-29 at 15:01 +0200, Takashi Iwai wrote:
At Fri, 29 Aug 2008 14:54:42 +0200, Harald Radke wrote:
Hi there!
Please be patient with me, I am quite inexperienced with alsa programming, so this might be a dumb question:
We have a WM8750 working in our PDA, the codec is working so far but I want to remove some of the control since they aren't needed.
Instead of copying the wm8750.c file and adjusting it, I want to write another module which basically get rid of those controls, something like:
[...]
static const char* unused_controls[] = {"AAAA", "BBBB,"CCCC"};
struct snd_kcontrol *ctl; list_for_each_entry(ctl, &card->controls, list)
You can't use list_for_each_entry() together with removal. Use list_for_each_entry_safe() for such a purpose.
But...
for(i=0; i < ARRAY_SIZE(unused_controls); i++) if (!strcmp(unused_controls[i],ctl->id.name)) { down_write(&card->controls_rwsem); snd_ctl_remove(card,ctl); up_write(&card->controls_rwsem); break; }
It'd be easier like the following:
for (i = 0; i < ARRAY_SIZE(unused_controls); i++) { struct snd_ctl_elem_id id; memset(&id, 0, sizeof(id)); strcpy(id.name, unused_controls[i]); id.iface = SNDRV_CTL_ELEM_IFACE_MIXER; snd_ctl_remove_id(card, &id); }
I'd prefer an addition to our API to handle this more _common_ case rather than just removing controls.
Something where we can mark controls as "disabled" so alsamixer and friends wont render/get them. This would also allow scenario code to disable relevant mixers and then re-enable when required.
Liam
At Fri, 29 Aug 2008 14:16:52 +0100, Liam Girdwood wrote:
On Fri, 2008-08-29 at 15:01 +0200, Takashi Iwai wrote:
At Fri, 29 Aug 2008 14:54:42 +0200, Harald Radke wrote:
Hi there!
Please be patient with me, I am quite inexperienced with alsa programming, so this might be a dumb question:
We have a WM8750 working in our PDA, the codec is working so far but I want to remove some of the control since they aren't needed.
Instead of copying the wm8750.c file and adjusting it, I want to write another module which basically get rid of those controls, something like:
[...]
static const char* unused_controls[] = {"AAAA", "BBBB,"CCCC"};
struct snd_kcontrol *ctl; list_for_each_entry(ctl, &card->controls, list)
You can't use list_for_each_entry() together with removal. Use list_for_each_entry_safe() for such a purpose.
But...
for(i=0; i < ARRAY_SIZE(unused_controls); i++) if (!strcmp(unused_controls[i],ctl->id.name)) { down_write(&card->controls_rwsem); snd_ctl_remove(card,ctl); up_write(&card->controls_rwsem); break; }
It'd be easier like the following:
for (i = 0; i < ARRAY_SIZE(unused_controls); i++) { struct snd_ctl_elem_id id; memset(&id, 0, sizeof(id)); strcpy(id.name, unused_controls[i]); id.iface = SNDRV_CTL_ELEM_IFACE_MIXER; snd_ctl_remove_id(card, &id); }
I'd prefer an addition to our API to handle this more _common_ case rather than just removing controls.
Something where we can mark controls as "disabled" so alsamixer and friends wont render/get them. This would also allow scenario code to disable relevant mixers and then re-enable when required.
Something like below?
Takashi
diff --git a/sound/core/control.c b/sound/core/control.c index 3c5e746..c6f7062 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -410,6 +410,52 @@ int snd_ctl_remove_id(struct snd_card *card, struct snd_ctl_elem_id *id) EXPORT_SYMBOL(snd_ctl_remove_id);
/** + * snd_ctl_activate_id - activate/inactivate the control of the given id + * @card: the card instance + * @id: the control id to activate/inactivate + * @active: non-zero to activate + * + * Finds the control instance with the given id, and activate or + * inactivate the control together with notification, if changed. + * + * Returns 0 if unchanged, 1 if changed, or a negative error code on failure. + */ +int snd_ctl_activate_id(struct snd_card *card, struct snd_ctl_elem_id *id, + int active) +{ + struct snd_kcontrol *kctl; + struct snd_kcontrol_volatile *vd; + unsigned int index_offset; + int ret; + + down_write(&card->controls_rwsem); + kctl = snd_ctl_find_id(card, id); + if (kctl == NULL) { + up_write(&card->controls_rwsem); + return -ENOENT; + } + index_offset = snd_ctl_get_ioff(kctl, &control->id); + vd = &kctl->vd[index_offset]; + ret = 0; + if (active) { + if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_INACTIVE)) + goto unlock; + vd->access &= ~SNDRV_CTL_ELEM_ACCESS_INACTIVE; + } else { + if (vd->access & SNDRV_CTL_ELEM_ACCESS_INACTIVE) + goto unlock; + vd->access |= SNDRV_CTL_ELEM_ACCESS_INACTIVE; + } + ret = 1; + unlock: + up_write(&card->controls_rwsem); + if (ret) + snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_INFO, id); + return ret; +} +EXPORT_SYMBOL(snd_ctl_activate_id); + +/** * snd_ctl_remove_unlocked_id - remove the unlocked control of the given id and release it * @file: active control handle * @id: the control id to remove
On Fri, 2008-08-29 at 15:41 +0200, Takashi Iwai wrote:
At Fri, 29 Aug 2008 14:16:52 +0100, Liam Girdwood wrote:
I'd prefer an addition to our API to handle this more _common_ case rather than just removing controls.
Something where we can mark controls as "disabled" so alsamixer and friends wont render/get them. This would also allow scenario code to disable relevant mixers and then re-enable when required.
Something like below?
Takashi
diff --git a/sound/core/control.c b/sound/core/control.c index 3c5e746..c6f7062 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -410,6 +410,52 @@ int snd_ctl_remove_id(struct snd_card *card, struct snd_ctl_elem_id *id) EXPORT_SYMBOL(snd_ctl_remove_id);
/**
- snd_ctl_activate_id - activate/inactivate the control of the given id
- @card: the card instance
- @id: the control id to activate/inactivate
- @active: non-zero to activate
- Finds the control instance with the given id, and activate or
- inactivate the control together with notification, if changed.
- Returns 0 if unchanged, 1 if changed, or a negative error code on failure.
- */
+int snd_ctl_activate_id(struct snd_card *card, struct snd_ctl_elem_id *id,
int active)
+{
- struct snd_kcontrol *kctl;
- struct snd_kcontrol_volatile *vd;
- unsigned int index_offset;
- int ret;
- down_write(&card->controls_rwsem);
- kctl = snd_ctl_find_id(card, id);
- if (kctl == NULL) {
up_write(&card->controls_rwsem);
return -ENOENT;
- }
- index_offset = snd_ctl_get_ioff(kctl, &control->id);
- vd = &kctl->vd[index_offset];
- ret = 0;
- if (active) {
if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_INACTIVE))
goto unlock;
vd->access &= ~SNDRV_CTL_ELEM_ACCESS_INACTIVE;
- } else {
if (vd->access & SNDRV_CTL_ELEM_ACCESS_INACTIVE)
goto unlock;
vd->access |= SNDRV_CTL_ELEM_ACCESS_INACTIVE;
- }
- ret = 1;
- unlock:
- up_write(&card->controls_rwsem);
- if (ret)
snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_INFO, id);
- return ret;
+} +EXPORT_SYMBOL(snd_ctl_activate_id);
+/**
- snd_ctl_remove_unlocked_id - remove the unlocked control of the given id and release it
- @file: active control handle
- @id: the control id to remove
Wow - that was quick !
Yes, exactly :) We can now add this to our machine drivers to disable never used controls (for each machine) and also call this when scenario changes too.
Even more interestingly, it could also be called by DAPM......
Cheers
Liam
At Fri, 29 Aug 2008 14:56:33 +0100, Liam Girdwood wrote:
On Fri, 2008-08-29 at 15:41 +0200, Takashi Iwai wrote:
At Fri, 29 Aug 2008 14:16:52 +0100, Liam Girdwood wrote:
I'd prefer an addition to our API to handle this more _common_ case rather than just removing controls.
Something where we can mark controls as "disabled" so alsamixer and friends wont render/get them. This would also allow scenario code to disable relevant mixers and then re-enable when required.
Something like below?
Takashi
diff --git a/sound/core/control.c b/sound/core/control.c index 3c5e746..c6f7062 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -410,6 +410,52 @@ int snd_ctl_remove_id(struct snd_card *card, struct snd_ctl_elem_id *id) EXPORT_SYMBOL(snd_ctl_remove_id);
/**
- snd_ctl_activate_id - activate/inactivate the control of the given id
- @card: the card instance
- @id: the control id to activate/inactivate
- @active: non-zero to activate
- Finds the control instance with the given id, and activate or
- inactivate the control together with notification, if changed.
- Returns 0 if unchanged, 1 if changed, or a negative error code on failure.
- */
+int snd_ctl_activate_id(struct snd_card *card, struct snd_ctl_elem_id *id,
int active)
+{
- struct snd_kcontrol *kctl;
- struct snd_kcontrol_volatile *vd;
- unsigned int index_offset;
- int ret;
- down_write(&card->controls_rwsem);
- kctl = snd_ctl_find_id(card, id);
- if (kctl == NULL) {
up_write(&card->controls_rwsem);
return -ENOENT;
- }
- index_offset = snd_ctl_get_ioff(kctl, &control->id);
- vd = &kctl->vd[index_offset];
- ret = 0;
- if (active) {
if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_INACTIVE))
goto unlock;
vd->access &= ~SNDRV_CTL_ELEM_ACCESS_INACTIVE;
- } else {
if (vd->access & SNDRV_CTL_ELEM_ACCESS_INACTIVE)
goto unlock;
vd->access |= SNDRV_CTL_ELEM_ACCESS_INACTIVE;
- }
- ret = 1;
- unlock:
- up_write(&card->controls_rwsem);
- if (ret)
snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_INFO, id);
- return ret;
+} +EXPORT_SYMBOL(snd_ctl_activate_id);
+/**
- snd_ctl_remove_unlocked_id - remove the unlocked control of the given id and release it
- @file: active control handle
- @id: the control id to remove
Wow - that was quick !
Yes, exactly :) We can now add this to our machine drivers to disable never used controls (for each machine) and also call this when scenario changes too.
Even more interestingly, it could also be called by DAPM......
Good to hear that. Just let me know if you need this in the upstream. I don't want to push such an API addition too early before any use.
FWIW, below is the latest version, found in my sound-unstable tree.
thanks,
Takashi
From c4ef566498f37140bcef852109e44bea580f4bc8 Mon Sep 17 00:00:00 2001 From: Takashi Iwai tiwai@suse.de Date: Fri, 29 Aug 2008 16:09:01 +0200 Subject: [PATCH] ALSA: Add snd_ctl_activate_id()
Added a new API function snd_ctl_activate_id() for activate / inactivate the control element dynamically.
Signed-off-by: Takashi Iwai tiwai@suse.de
diff --git a/include/sound/control.h b/include/sound/control.h index 4721b4b..6c0002a 100644 --- a/include/sound/control.h +++ b/include/sound/control.h @@ -114,6 +114,8 @@ int snd_ctl_add(struct snd_card * card, struct snd_kcontrol * kcontrol); int snd_ctl_remove(struct snd_card * card, struct snd_kcontrol * kcontrol); int snd_ctl_remove_id(struct snd_card * card, struct snd_ctl_elem_id *id); int snd_ctl_rename_id(struct snd_card * card, struct snd_ctl_elem_id *src_id, struct snd_ctl_elem_id *dst_id); +int snd_ctl_activate_id(struct snd_card * card, struct snd_ctl_elem_id *id, + int active); struct snd_kcontrol *snd_ctl_find_numid(struct snd_card * card, unsigned int numid); struct snd_kcontrol *snd_ctl_find_id(struct snd_card * card, struct snd_ctl_elem_id *id);
diff --git a/sound/core/control.c b/sound/core/control.c index 3c5e746..c6f7062 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -410,6 +410,52 @@ int snd_ctl_remove_id(struct snd_card *card, struct snd_ctl_elem_id *id) EXPORT_SYMBOL(snd_ctl_remove_id);
/** + * snd_ctl_activate_id - activate/inactivate the control of the given id + * @card: the card instance + * @id: the control id to activate/inactivate + * @active: non-zero to activate + * + * Finds the control instance with the given id, and activate or + * inactivate the control together with notification, if changed. + * + * Returns 0 if unchanged, 1 if changed, or a negative error code on failure. + */ +int snd_ctl_activate_id(struct snd_card *card, struct snd_ctl_elem_id *id, + int active) +{ + struct snd_kcontrol *kctl; + struct snd_kcontrol_volatile *vd; + unsigned int index_offset; + int ret; + + down_write(&card->controls_rwsem); + kctl = snd_ctl_find_id(card, id); + if (kctl == NULL) { + up_write(&card->controls_rwsem); + return -ENOENT; + } + index_offset = snd_ctl_get_ioff(kctl, &control->id); + vd = &kctl->vd[index_offset]; + ret = 0; + if (active) { + if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_INACTIVE)) + goto unlock; + vd->access &= ~SNDRV_CTL_ELEM_ACCESS_INACTIVE; + } else { + if (vd->access & SNDRV_CTL_ELEM_ACCESS_INACTIVE) + goto unlock; + vd->access |= SNDRV_CTL_ELEM_ACCESS_INACTIVE; + } + ret = 1; + unlock: + up_write(&card->controls_rwsem); + if (ret) + snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_INFO, id); + return ret; +} +EXPORT_SYMBOL(snd_ctl_activate_id); + +/** * snd_ctl_remove_unlocked_id - remove the unlocked control of the given id and release it * @file: active control handle * @id: the control id to remove
On Fri, 2008-08-29 at 18:42 +0200, Takashi Iwai wrote:
At Fri, 29 Aug 2008 14:56:33 +0100, Liam Girdwood wrote:
Yes, exactly :) We can now add this to our machine drivers to disable never used controls (for each machine) and also call this when scenario changes too.
Even more interestingly, it could also be called by DAPM......
Good to hear that. Just let me know if you need this in the upstream. I don't want to push such an API addition too early before any use.
I agree, although I'm now not is a position to test anything atm (no hardware until later next week).
Harald, could you give this a try with your WM8750 based device. Please feel free to mail with any questions you may have re WM8750 mixers.
Thanks
Liam
hm.... I added the function and the declaration to our 2.6.26 tree, compiling gives:
sound/core/control.c: In function `snd_ctl_activate_id': sound/core/control.c:435: error: `control' undeclared (first use in this function)
is it essential to use your devel tree?
Harry
PS: Liam: thanks for the offer, I am sure I will bug u with unqualified questions till the sound support on our Loox works as wanted (; And nice work on the 8750 codec!
At Sat, 30 Aug 2008 00:19:05 +0200, Harald Radke wrote:
hm.... I added the function and the declaration to our 2.6.26 tree, compiling gives:
sound/core/control.c: In function `snd_ctl_activate_id': sound/core/control.c:435: error: `control' undeclared (first use in this function)
Ah, it's an obvious typo. Replace control with ctl in line 435.
is it essential to use your devel tree?
Better, but for this particular change, it's not important.
Takashi
Harry
PS: Liam: thanks for the offer, I am sure I will bug u with unqualified questions till the sound support on our Loox works as wanted (; And nice work on the 8750 codec! _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hi there!
Well, I guessed it was a typo but you know, with software u barely know, one is a little bit more careful (:
Ok, I tested the activated() routine, it works quite well for deactivating, those controls aren't available in mixer user apps as well as deactivating a control which is necessary for sound output like "Left Mixer Playback Switch" (on WM8750) mutes the device (:
However, I tried the following:
- deactivate control - activate same control (right after deactivating)
with the effect that the control wasn't accessible via mixer nor did the related path seem to work
Greez,
Harry
Ok, I just checked my source and realized I messed things up...
deactivating AND activating work, the control is not accessible via mixer, however sound paths the control is related to still are functional
My bad, sorry sorry sorry
Harry
On Mon, 2008-09-01 at 13:09 +0200, Harald Radke wrote:
Ok, I just checked my source and realized I messed things up...
deactivating AND activating work, the control is not accessible via mixer, however sound paths the control is related to still are functional
That's good to hear that things are working. The sound paths that are related to disabled controls may still need to be functional depending on the audio use case.
Liam
Am Montag 01 September 2008 13:51:10 schrieb Liam Girdwood:
On Mon, 2008-09-01 at 13:09 +0200, Harald Radke wrote:
Ok, I just checked my source and realized I messed things up...
deactivating AND activating work, the control is not accessible via mixer, however sound paths the control is related to still are functional
That's good to hear that things are working. The sound paths that are related to disabled controls may still need to be functional depending on the audio use case.
Well, actually that is exactly what I need, so this wasn't a complain (: as I e.g. want to deactivate all mixer device settings in mixer utils, however, set the mixer DAC input correctly. If deactivated controls were breaking soundpaths, I had to "rewire" them...
Hm, a great thing would be to have something like "codec_instanciate()" where u could select a codec device and an array with control names and values for items to be deactivated and get the "modified" codec...but I guess that would be ways to high level for the sound driver structure (;
Greez,
Harry
PS: keep up ur great work folks and thank you!
On Tue, Sep 02, 2008 at 10:02:13AM +0200, Harald Radke wrote:
Hm, a great thing would be to have something like "codec_instanciate()" where u could select a codec device and an array with control names and values for items to be deactivated and get the "modified" codec...but I guess that would be ways to high level for the sound driver structure (;
For the greatest flexibility you really want the activation and deactivation to be doable via user space - many devices (especially complex ones like smartphones) can run with several different audio setups and need to change between them on the fly at run time. Trying to encode all the possible scenarios in the kernel makes for a relatively large amount of work when there are a lot of options.
Liam has been working on an API to facilitate that sort of scenario setup:
For the greatest flexibility you really want the activation and deactivation to be doable via user space - many devices (especially complex ones like smartphones) can run with several different audio setups and need to change between them on the fly at run time. Trying to encode all the possible scenarios in the kernel makes for a relatively large amount of work when there are a lot of options.
(: I didn't mean to hide activation/deactivation of controls from userspace by spinning the idea of an codec instantiation but merely as a convenient base setup for devices...in fact I always prefer larger system interfaces compared to locked up ones
Harry
participants (4)
-
Harald Radke
-
Liam Girdwood
-
Mark Brown
-
Takashi Iwai