Dne 11. 11. 19 v 14:39 Jaroslav Kysela napsal(a):

Dne 07. 11. 19 v 2:57 Curtis Malainey napsal(a):

...

Identifies the type of jack and how it should be accessed

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 2051bd40..3208cc30 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -322,6 +322,9 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr, * configuration that doesn't belong to UCM configuration files. * - JackName * - Input name is the input device name for the jack

• • • JackType

• •  - Specifies whether the jack is accessed via hctl or gpio and therefore
    

• •    only carries the possible values of "gpio" or "hctl"
    

    */
  int snd_use_case_get(snd_use_case_mgr_t *uc_mgr, const char *identifier,

What is meant with the "gpio" type? The standard input device interface? I believe it should be "inputdev" and "ctl" (hctl is just interface on top of ctl and the application can access the jack through snd_ctl functions, too.

I see (when I was cleaning this extra Chrome stuff in the ucm profiles) that it's related to the gpio (general purpose i/o pin interface) in the linux kernel. The JackSwitch is probably also related and defines the pin number where the application should watch for the jack state. In this case, it would be probably more nice to follow the JackControl and JackDev and define the pin number through JackGPIO or something like that. We will cover all three posibilities: ALSA control interface, Input interface, GPIO interface .

Jaroslav

Dne 03. 12. 19 v 4:22 Curtis Malainey napsal(a):

On Fri, Nov 29, 2019 at 8:01 AM Jaroslav Kysela perex@perex.cz wrote:

...

Dne 11. 11. 19 v 14:39 Jaroslav Kysela napsal(a):

...

Dne 07. 11. 19 v 2:57 Curtis Malainey napsal(a):

...

Identifies the type of jack and how it should be accessed

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 2051bd40..3208cc30 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -322,6 +322,9 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr, * configuration that doesn't belong to UCM configuration files. * - JackName * - Input name is the input device name for the jack

• • • JackType

• •  - Specifies whether the jack is accessed via hctl or gpio and therefore
    

• •    only carries the possible values of "gpio" or "hctl"
    

    */ int snd_use_case_get(snd_use_case_mgr_t *uc_mgr, const char *identifier,

What is meant with the "gpio" type? The standard input device interface? I believe it should be "inputdev" and "ctl" (hctl is just interface on top of ctl and the application can access the jack through snd_ctl functions, too.

I see (when I was cleaning this extra Chrome stuff in the ucm profiles) that it's related to the gpio (general purpose i/o pin interface) in the linux kernel. The JackSwitch is probably also related and defines the pin number where the application should watch for the jack state. In this case, it would be probably more nice to follow the JackControl and JackDev and define the pin number through JackGPIO or something like that. We will cover all three posibilities: ALSA control interface, Input interface, GPIO interface .

                                     Jaroslav

Initially that was our thoughts too but then we realized that in the event of a new theoretical input subsystem "foo" that can be used for jack detect then we would need to create another field for that as well. This reduces the need for having a field for every theoretical subsystem in the future and only then requires a new value.

The JackDev and JackControl was defined in 2015. If we decide to switch to:

JackType "(gpio|ctl|inputdev)" JackSwitch "(gpio pin|ctl jack control name|input device name)"

.. then we need to adapt pulseaudio, too.

Anyway, JackDev/JackControl allows to use both definitions simultaneously, thus the application can choose the interface as preferred (and available).

The gpio looks like a hack for drivers which does not have this abstraction (input device or ALSA's jack) implemented. The gpio pin value can be passed using the device tree to the driver.

Jaroslav

Dne 07. 11. 19 v 2:58 Curtis Malainey napsal(a):

Identifies event code that will be sent by the device on an jack detect event

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 3208cc30..a79e5b91 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -322,6 +322,9 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

•    configuration that doesn't belong to UCM configuration files.
  

• • JackName

•  - Input name is the input device name for the jack
  

• • • JackSwitch

• •  - The type of event code the jack will send, corresponds to
    

• •    Switch Events in include/uapi/linux/input-event-codes.h in the kernel
    

  • • JackType

  •  - Specifies whether the jack is accessed via hctl or gpio and therefore
    

  •    only carries the possible values of "gpio" or "hctl"
    
    

It's a string or hexa value or so? It requires a better description.

Jaroslav

Dne 07. 11. 19 v 2:58 Curtis Malainey napsal(a):

Add a sys path to the EDID file for the corresponding HDMI device so userspace can use if needed

Signed-off-by: Curtis Malainey cujomalainey@chromium.org

include/use-case.h | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/include/use-case.h b/include/use-case.h index a79e5b91..28e92d17 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -301,6 +301,8 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

•  - name of capture mixer
  

• • CaptureMixerID

•  - mixer capture ID
  

• • • EDIDFile

• •  - Path to EDID file for HDMI devices
    

  • • JackControl, JackDev, JackHWMute

  •  - Jack information for a device. The jack status can be reported via
    

  •    a kcontrol and/or via an input device. **JackControl** is the
    
    

Applied to alsa-lib's git tree:

https://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=ef085a55c488f64834fc...

Thanks, Jaroslav

Dne 07. 11. 19 v 2:58 Curtis Malainey napsal(a):

Allows ucm to override minimum buffer level for platforms that incorrectly report their buffer level.

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 28e92d17..05628303 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -330,6 +330,10 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

• • JackType

•  - Specifies whether the jack is accessed via hctl or gpio and therefore
  

•    only carries the possible values of "gpio" or "hctl"
  

• • • 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
    

• •    increase latency.
    

  */ int snd_use_case_get(snd_use_case_mgr_t *uc_mgr, const char *identifier,

This is something like the BATCH flag we have in the PCM API. It would be probably nice to add this to the PCM API, too. Takashi?

Jaroslav

On Mon, Nov 11, 2019 at 7:22 AM Jaroslav Kysela perex@perex.cz wrote:

Dne 07. 11. 19 v 2:58 Curtis Malainey napsal(a):

...

Some userspace audio servers might default to software volume, this allows the ucm to force its behaviour

Signed-off-by: Curtis Malainey cujomalainey@chromium.org

include/use-case.h | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/include/use-case.h b/include/use-case.h index 05628303..1aeaf9d4 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -334,6 +334,8 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

•  - 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
  

•    increase latency.
  

• • • DisableSoftwareVolume

• •  - Set to "1" to force userspace to use hardware volume controls
    

  */ int snd_use_case_get(snd_use_case_mgr_t *uc_mgr, const char *identifier,

My understanding is that if the hardware volume controls are defined in UCM, then the UCM user (audio server) should use them. Otherwise, the software volume control should be applied. I don't see the reason to have this info doubled.

                                    Jaroslav

+Jimmy Cheng-Yi Chiang can you clarify in what context CRAS might need this value? The only cases I see are for Chat 150 C and Jabra SPEAK 810. There are no volume mixers associated with these files.

-- Jaroslav Kysela perex@perex.cz Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

On Mon, Nov 11, 2019 at 7:30 AM Jaroslav Kysela perex@perex.cz wrote:

Dne 07. 11. 19 v 2:58 Curtis Malainey napsal(a):

...

Add ucm value to tell userspace to remap channels. This is useful for systems with DMICs where there may be more channels than active channels.

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 1aeaf9d4..31f9e4be 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -301,6 +301,10 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

•  - name of capture mixer
  

• • CaptureMixerID

•  - mixer capture ID
  

• • • CaptureChannelMap

• •  - Remap channels using ALSA PCM channel mapping API notation
    

• •    E.g. "2 3 0 1 -1 -1 -1 -1 -1 -1 -1" means, FL takes channel 2,
    

• •    FR takes channel 3, RL takes channel 0, RL takes channel 1.
    

  • • EDIDFile

  •  - Path to EDID file for HDMI devices
    

  • • JackControl, JackDev, JackHWMute

I see a room for the improvement to have a better and complete mapping description like:

CaptureChannelMap "FR=0 RL=1 TC=2"

The location names should follow SND_CHMAP defines.

                                    Jaroslav

I am definitely for that modification as the mapping for the plugin is not easy to read, that being said, do we have a tool to handle parsing/converting that from a string already? I feel like we should add one if we are going to make that the spec.

-- Jaroslav Kysela perex@perex.cz Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

On Wed, Nov 6, 2019 at 5:58 PM Curtis Malainey cujomalainey@chromium.org wrote:

Explains to userspace how some channels may need to be rearranged. This is useful for systems that may have DMIC pcms with dead channels that will need remapping.

Apologies this is the coupled mixer patch, this is an error. I will resend this with anything else that needs to be corrected

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 31f9e4be..9a10f390 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -305,6 +305,9 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

•  - Remap channels using ALSA PCM channel mapping API notation
  

•    E.g. "2 3 0 1 -1 -1 -1 -1 -1 -1 -1" means, FL takes channel 2,
  

•    FR takes channel 3, RL takes channel 0, RL takes channel 1.
  

• • • CoupledMixers

• •  - Mixer controls that should be changed together.
    

• •    E.g. "Left Master,Right Master".
    

  • • EDIDFile

  •  - Path to EDID file for HDMI devices
    

  • • JackControl, JackDev, JackHWMute

-- 2.24.0.432.g9d3f5f5b63-goog

On Mon, Nov 11, 2019 at 7:32 AM Jaroslav Kysela perex@perex.cz wrote:

Dne 07. 11. 19 v 2:58 Curtis Malainey napsal(a):

...

Explains to userspace how some channels may need to be rearranged. This is useful for systems that may have DMIC pcms with dead channels that will need remapping.

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 31f9e4be..9a10f390 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -305,6 +305,9 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

•  - Remap channels using ALSA PCM channel mapping API notation
  

•    E.g. "2 3 0 1 -1 -1 -1 -1 -1 -1 -1" means, FL takes channel 2,
  

•    FR takes channel 3, RL takes channel 0, RL takes channel 1.
  

• • • CoupledMixers

• •  - Mixer controls that should be changed together.
    

• •    E.g. "Left Master,Right Master".
    

  • • EDIDFile

  •  - Path to EDID file for HDMI devices
    

  • • JackControl, JackDev, JackHWMute

I do not see which names are referred by this. It's for the snd_ctl interface or for the simple mixer ?

                                            Jaroslav

Yes, this would be referring to volume mixers in amixer.

-- Jaroslav Kysela perex@perex.cz Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Dne 07. 11. 19 v 2:58 Curtis Malainey napsal(a):

Sometimes userspace may want to use a reference channel to cancel echos when using video chat, this value identifies the device which carries that channel.

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 9a10f390..e84f3f8f 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -308,6 +308,9 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

• • CoupledMixers

•  - Mixer controls that should be changed together.
  

•    E.g. "Left Master,Right Master".
  

• • • EchoReferenceDev

• •  - If userspace wants an echo refence channel this value identifies the
    

• •    device to be used.
    

  • • EDIDFile

  •  - Path to EDID file for HDMI devices
    

  • • JackControl, JackDev, JackHWMute

It's PCM device name like PlaybackPCM ? I would rename this to EchoReferencePCM then.

Jaroslav

On Mon, Nov 11, 2019 at 7:33 AM Jaroslav Kysela perex@perex.cz wrote:

Dne 07. 11. 19 v 2:58 Curtis Malainey napsal(a):

...

Add software gain ucm definition.

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 e84f3f8f..ee6ee5e0 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -344,6 +344,9 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

•  - 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
  

•    increase latency.
  

• • • SoftwareGain

• •  - Specify the software gain in 0.01dB. E.g. "20" means there will be
    

• •    0.2 dB software gain on this node.
    

  • • DisableSoftwareVolume

  •  - Set to "1" to force userspace to use hardware volume controls
    

  */

In other words, it's the recommended software gain control? The description should be improved then.

                                            Jaroslav

Not the control/mixer, in this case it is a gain value that is expected to be applied by the audio server (should the server parse it)

-- Jaroslav Kysela perex@perex.cz Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Dne 07. 11. 19 v 2:58 Curtis Malainey napsal(a):

Allow ucm to specify a default hardware gain to overide on the respective node.

Signed-off-by: Curtis Malainey cujomalainey@chromium.org

include/use-case.h | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/include/use-case.h b/include/use-case.h index ee6ee5e0..d0e821d5 100644 --- a/include/use-case.h +++ b/include/use-case.h @@ -347,6 +347,8 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,

• • SoftwareGain

•  - Specify the software gain in 0.01dB. E.g. "20" means there will be
  

•    0.2 dB software gain on this node.
  

• • • DefaultNodeGain

• •  - Change the default node gain. E.g: “-700” to set -7 dB on this node
    

  • • DisableSoftwareVolume

  •  - Set to "1" to force userspace to use hardware volume controls
    

  */

I don't see the usage. Could you elaborate a bit which purpose is for this value?

Jaroslav