[PATCH 1/2] ucm: Add JackSwitch definition

[PATCH 1/2] ucm: Add JackSwitch definition

[Curtis Malainey]

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
-- 
2.28.0.297.g1956fa8f8d-goog

[PATCH 2/2] ucm: add DmaPeriodMicrosecs

[Curtis Malainey]

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
-- 
2.28.0.297.g1956fa8f8d-goog

Re: [PATCH 1/2] ucm: Add JackSwitch definition

[Alper Nebi Yasak]

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).

Re: [PATCH 1/2] ucm: Add JackSwitch definition

[Curtis Malainey]

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.

Re: [PATCH 1/2] ucm: Add JackSwitch definition

[Alper Nebi Yasak]

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.

Re: [PATCH 1/2] ucm: Add JackSwitch definition

[Curtis Malainey]

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 :)