> > I see. In this case, the auto-route settings should differ from the
> > mixer settings. So the mute flag should be logical _OR_ from both DAPM
> > and the mixer settings. And because the codec is able to do the hw
> > mute, why to prevent the export of this feature?
> >
> > So I propose do do (pseudo code):
> >
> > struct rt711_sdca_priv {
> > bool fu0f_dapm_mute;
> > bool fu0f_mixer_mute;
> > };
> >
> > /* called from both dapm event and kontrol put callback (on change) */
> > /* the dapm event and put callback will modify only rt711_sdca_priv
> > fields */ static void set_f0f_mute(rt711_priv) {
> > int mute = rt711_priv->fu0f_dapm_mute || rt711_priv-
> > >fu0f_mixer_mute;
> > set_fu0f_mute_register(mute);
> > }
> >
> > With this implementation, all is consistent to the user space.
>
> If so:
> When capture, if user setting is mute, it will always mute and if user setting is
> unmute, it will always unmute.
>
> When stop capture, it will always mute regardless the user setting.
>
> Shuming, what do you think?
I think the function could mute/unmute both. It could avoid that the setting always mutes if the user setting is unmute.
e.g.
static void set_fu0f_capture_ctl(rt711_priv) {
int mute = rt711_priv->fu0f_dapm_mute || rt711_priv->fu0f_mixer_mute;
if (mute)
set_fu0f_mute_register();
else
set_fu0f_unmute_register();
}
Hi Jaroslav,
Thanks for your suggestions. After the testing, I will send the v2 version.
> >
> > >> Anyway, the switch and volume for the given I/O should have
> > >> identical name and they should differ only in the suffix describing
> > >> the stream and functionality.
> > >
> > > We won't touch "CaptureSwitch" and "CaptureVolume" for rt711-sdca.
> >
> > Yes, but the hw controls should be used instead DSP controls, if they
> > are available.
>
> Yes, we will try to use the codec hw controls instead of the DSP controls.
>
> Regards,
> Libin
> ------Please consider the environment before printing this e-mail.
