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.