Dne 20. 04. 21 v 3:10 Shuming [范書銘] napsal(a):
>>> 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();
> }
Yes, I passed the mute value in the pseudo code to the
set_fu0f_mute_register() function as argument for the further evaluation, but
I meant exactly this.
Thank you,
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
