Hi CK, Hi Mark, (I've added Mark - since he committed the original soc-ops line of code below - and the list)
On Mon, 7 Dec 2015 07:30:07 +0100 Code Kipper <[email protected]> wrote: [...] > > +static DECLARE_TLV_DB_SCALE(sun4i_codec_linein_output_volume_scale, -150, > > 150, 0); > These aren't really volume...that is handled by the Pre-Amp and I'd > argue playback . I agree that these are playback controls. >I would call this loopback gain. [...] > > + SOC_SINGLE_TLV("Line-In Playback Volume", > ditto [... sun4i_codec_linein_output_volume_scale] Just to make sure, you mean that, for the user, it should be shown as "Line-In Loopback Gain"? I tried to make that work, but by now I had to patch alsa-lib and other parts of the kernel as well. I'm still not sure whether I found all the parts that need changing. So the summary is that this name is both a displaystring AND has meaning to the system. If I call it "Line-In Loopback Gain" and not change alsa-lib, then alsamixer will show it as a boolean control (which it isn't :P). If I call it "Line-In Loopback Gain" and patch alsa-lib, the control will vanish from alsamixer (!). If I call it like that, patch alsa-lib and patch sound/soc/soc-ops.c, then it will work again. Btw: If one forgets do to some of the patches and/or not everything is installed at once on the user's computer, the Line-In control will just vanish as if it never existed (!). So if you don't feel strongly about this, I'd rather not do all that and just call it "Line-In Playback Volume" instead. (There are possible workarounds like overwriting .info in the struct snd_kcontrol_new instance in order to prevent it from claiming that it is a boolean control) The relevant pseudo-patches (NOT FINISHED - and including some debugging messages for sanity) are: To linux-next: diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c index a513a34..20407d9 100644 --- a/sound/soc/soc-ops.c +++ b/sound/soc/soc-ops.c @@ -194,7 +194,7 @@ int snd_soc_info_volsw(struct snd_kcontrol *kcontrol, mc->platform_max = mc->max; platform_max = mc->platform_max; - if (platform_max == 1 && !strstr(kcontrol->id.name, " Volume")) + if (platform_max == 1 && !strstr(kcontrol->id.name, " Volume") && ...not gain either) uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; else uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; I'm thinking about adding "!kcontrol->tlv.p" as a catch-all... not sure, though. @Mark, what do you think about that? To alsa-lib-1.0.28: --- orig/alsa-lib-1.0.28/src/mixer/simple_none.c 2014-06-17 12:34:19.000000000 +0000 +++ alsa-lib-1.0.28/src/mixer/simple_none.c 2015-12-11 21:43:57.314549129 +0000 @@ -892,10 +892,13 @@ {" Playback Switch", CTL_PLAYBACK_SWITCH}, {" Playback Route", CTL_PLAYBACK_ROUTE}, {" Playback Volume", CTL_PLAYBACK_VOLUME}, + {" Loopback Switch", CTL_PLAYBACK_SWITCH}, + {" Loopback Gain", CTL_PLAYBACK_VOLUME}, {" Capture Enum", CTL_CAPTURE_ENUM}, {" Capture Switch", CTL_CAPTURE_SWITCH}, {" Capture Route", CTL_CAPTURE_ROUTE}, {" Capture Volume", CTL_CAPTURE_VOLUME}, + {" Boost Gain", CTL_CAPTURE_VOLUME}, {" Enum", CTL_GLOBAL_ENUM}, {" Switch", CTL_GLOBAL_SWITCH}, {" Route", CTL_GLOBAL_ROUTE}, @@ -909,6 +912,7 @@ { const struct suf *p; size_t nlen = strlen(name); + fprintf(stderr, "base_len(%s)\n", name); p = suffixes; while (p->suffix) { size_t slen = strlen(p->suffix); @@ -918,6 +922,7 @@ if (strncmp(name + l, p->suffix, slen) == 0 && (l < 1 || name[l-1] != '-')) { /* 3D Control - Switch */ *type = p->type; + fprintf(stderr, "-> type %u\n", (unsigned) *type); return l; } } @@ -1487,6 +1492,7 @@ case CTL_GLOBAL_VOLUME: case CTL_PLAYBACK_VOLUME: case CTL_CAPTURE_VOLUME: + fprintf(stderr, "control type is playback volume? %u\n", (unsigned) type == CTL_PLAYBACK_VOLUME); if (ctype == SND_CTL_ELEM_TYPE_ENUMERATED) { if (type == CTL_PLAYBACK_VOLUME) type = CTL_PLAYBACK_ENUM; @@ -1496,6 +1502,7 @@ type = CTL_GLOBAL_ENUM; break; } + fprintf(stderr, "ctype is integer? %u; ctype=%u\n", (unsigned) ctype == SND_CTL_ELEM_TYPE_INTEGER, (unsigned) ctype); if (ctype != SND_CTL_ELEM_TYPE_INTEGER) return 0; break; Arrrgh... But we can try your way for the Mic gains, they have larger range and can't be misrepresented as a boolean. That would still need an alsa-lib patch to make it recognize it as a capturing control, though. Thanks, Danny -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
