[PATCH 1/2] ucm: Add JackSwitch definition
Some codecs can differentiate headsets based on the number of rings. Should we choose to differentiate the config we will need to be able to select based on the jack event code.
Signed-off-by: Curtis Malainey cujomalainey@chromium.org --- include/use-case.h | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/include/use-case.h b/include/use-case.h index 2363c3ed..80148a7b 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -386,6 +386,9 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr, * to e.g. automatically mute speakers when headphones are plugged in, * but that's application policy configuration that doesn't belong * to UCM configuration files. + * - JackSwitch + * - Represents the jack switch value for this device. Value is a base 10 + * value of a switch code in input_event_codes.h * - MinBufferLevel * - This is used on platform where reported buffer level is not accurate. * E.g. "512", which holds 512 samples in device buffer. Note: this will
Add ucm value to allow userspace to set sane values for platforms that default to be configs.
Signed-off-by: Curtis Malainey cujomalainey@chromium.org --- include/use-case.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/use-case.h b/include/use-case.h index 80148a7b..94992cd4 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -358,6 +358,10 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr, * - CaptureMasterType * - type of the master volume control * - Valid values: "soft" (software attenuation) + * - DmaPeriodMicrosecs + * - Set DMA period us. Used to correct when system defaults to values too + * large which cause initial noise. Value is passed to + * snd_pcm_hw_params_set_period_time_near. * - EDIDFile * - Path to EDID file for HDMI devices * - JackCTL
Hi, I'm not really a kernel person, but wanted to point out an alternative I think is better.
On 21/08/2020 02:32, Curtis Malainey wrote:
Some codecs can differentiate headsets based on the number of rings. Should we choose to differentiate the config we will need to be able to select based on the jack event code.
AFAICT from ChromiumOS UCM configs, you're using JackSwitch to detect whether a plugged-in jack is/has headphones, a headset mic, or line-out. Instead, if you add something like my recent commit d0508b4f1604 ("ASoC: rk3399_gru_sound: Add DAPM pins, kcontrols for jack detection") to the machine drivers, you can just use JackControl to specify them in your UCM files, and your audio server could distinguish between those cases by the values of the jack kcontrols (e.g. PulseAudio already can).
On Sat, Aug 22, 2020 at 6:48 AM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi, I'm not really a kernel person, but wanted to point out an alternative I think is better.
On 21/08/2020 02:32, Curtis Malainey wrote:
Some codecs can differentiate headsets based on the number of rings. Should we choose to differentiate the config we will need to be able to select based on the jack event code.
AFAICT from ChromiumOS UCM configs, you're using JackSwitch to detect whether a plugged-in jack is/has headphones, a headset mic, or line-out. Instead, if you add something like my recent commit d0508b4f1604 ("ASoC: rk3399_gru_sound: Add DAPM pins, kcontrols for jack detection") to the machine drivers, you can just use JackControl to specify them in your UCM files, and your audio server could distinguish between those cases by the values of the jack kcontrols (e.g. PulseAudio already can).
Typically we use JackDev over JackControl, and this would add similar support to what you added but within the context of using an input device instead of an ALSA jack.
On 22/08/2020 20:07, Curtis Malainey wrote:
Typically we use JackDev over JackControl, and this would add similar support to what you added but within the context of using an input device instead of an ALSA jack.
Oh, I forgot JackDev was actually an upstream thing and thought it was ChromeOS-specific. In that case I can't really object to JackSwitch either.
Still, problems with jack detection are common for people who want to use ordinary Linux distributions on ChromeOS devices and from my point of view it's "Google makes their things run on JackControl" vs "Someone makes PulseAudio etc. support JackDev+JackSwitch" to get things working out of the box in the future. I was trying to propose the former, but I don't know the merits of either approach, so can't say much other than that.
Regardless, I appreciate your work on reconciling ChromeOS configs with upstream configs.
On Sat, Aug 22, 2020 at 11:33 AM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
On 22/08/2020 20:07, Curtis Malainey wrote:
Typically we use JackDev over JackControl, and this would add similar support to what you added but within the context of using an input device instead of an ALSA jack.
Oh, I forgot JackDev was actually an upstream thing and thought it was ChromeOS-specific. In that case I can't really object to JackSwitch either.
Still, problems with jack detection are common for people who want to use ordinary Linux distributions on ChromeOS devices and from my point of view it's "Google makes their things run on JackControl" vs "Someone makes PulseAudio etc. support JackDev+JackSwitch" to get things working out of the box in the future. I was trying to propose the former, but I don't know the merits of either approach, so can't say much other than that.
I understand that, which is why I am trying to pull our configs into alignment. Currently we support JackControl or JackDev (I believe as of january.) And I am gradually pulling the rest of the configs into alignment. I think given the fact that JackDev is an upstream construct we should make it match feature parity with JackControl.
Regardless, I appreciate your work on reconciling ChromeOS configs with upstream configs.
Thanks :)
participants (3)
-
Alper Nebi Yasak -
Curtis Malainey -
Curtis Malainey