April 2021 - Alsa-devel - mailman.alsa-project.org

[PATCH] ALSA: usb-audio: Remove redundant assignment to len
by Jiapeng Chong 28 Apr '21

28 Apr '21

Variable len is set to zero but this value is never read as it is overwritten with a new value later on, hence it is a redundant assignment and can be removed. Cleans up the following clang-analyzer warning: sound/usb/mixer.c:2713:3: warning: Value stored to 'len' is never read [clang-analyzer-deadcode.DeadStores]. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- sound/usb/mixer.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index b004b2e..937bc17 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -2710,7 +2710,6 @@ static int parse_audio_selector_unit(struct mixer_build *state, int unitid, #define MAX_ITEM_NAME_LEN 64 for (i = 0; i < desc->bNrInPins; i++) { struct usb_audio_term iterm; - len = 0; namelist[i] = kmalloc(MAX_ITEM_NAME_LEN, GFP_KERNEL); if (!namelist[i]) { err = -ENOMEM; -- 1.8.3.1

2 1

[PATCH] ALSA: hda/realtek: Add quirk for Intel Clevo PCx0Dx
by Werner Sembach 28 Apr '21

28 Apr '21

From: Eckhart Mohr <e.mohr(a)tuxedocomputers.com> This applies a SND_PCI_QUIRK(...) to the Clevo PCx0Dx barebones. This fix enables audio output over the headset jack and ensures that a microphone connected via the headset combo jack is correctly recognized when pluged in. Signed-off-by: Eckhart Mohr <e.mohr(a)tuxedocomputers.com> Co-developed-by: Werner Sembach <wse(a)tuxedocomputers.com> Signed-off-by: Werner Sembach <wse(a)tuxedocomputers.com> Cc: <stable(a)vger.kernel.org> --- >From 7dee2aee3ab045c4dafa9793a4016929a559d9cd Mon Sep 17 00:00:00 2001 From: Werner Sembach <wse(a)tuxedocomputers.com> Date: Tue, 13 Apr 2021 14:02:08 +0200 Subject: [PATCH] Add SND_PCI_QUIRK for Clevo PCx0Dx --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index a7544b77d3f7..dba9fd27adec 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -2555,6 +2555,8 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = { SND_PCI_QUIRK(0x1558, 0x67d1, "Clevo PB71[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS), SND_PCI_QUIRK(0x1558, 0x67e1, "Clevo PB71[DE][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS), SND_PCI_QUIRK(0x1558, 0x70d1, "Clevo PC70[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS), + SND_PCI_QUIRK(0x1558, 0x65e5, "Clevo PC50D[PRS](?:-D|-G)?", ALC1220_FIXUP_CLEVO_PB51ED_PINS), + SND_PCI_QUIRK(0x1558, 0x67e5, "Clevo PC70D[PRS](?:-D|-G)?", ALC1220_FIXUP_CLEVO_PB51ED_PINS), SND_PCI_QUIRK(0x1558, 0x7714, "Clevo X170", ALC1220_FIXUP_CLEVO_PB51ED_PINS), SND_PCI_QUIRK_VENDOR(0x1558, "Clevo laptop", ALC882_FIXUP_EAPD), SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_FIXUP_EAPD), -- 2.25.1

2 1

ucm2: soundwire: use the codec kcontrols for rt711-sdca
by GitHub pull_request - opened 28 Apr '21

28 Apr '21

alsa-project/alsa-ucm-conf pull request #90 was opened from libinyang: Use "rt711 FU0F" as the HW control, instead of the "PGA2.0 2". Signed-off-by: Libin Yang <libin.yang(a)intel.com> Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/90 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/90.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Intro to Topology2.0
by GitHub pull_request - opened 28 Apr '21

28 Apr '21

alsa-project/alsa-utils pull request #86 was opened from ranj063: Add support for pre-processing Topology2.0 conf file and building the tplg binary. An example implementation of topology with Topology2.0 can be found here: https://github.com/thesofproject/sof/pull/3983 Introduction to Topology 2.0 ----- Topology2.0 is a high level keyword extension on top of the existing ALSA conf topology format designed to: 1) Simplify the ALSA conf topology definitions by providing high level "classes" so topology designers need to write less config for common object definitions. 2) Allow simple reuse of objects. Define once and reuse (like M4) with the ability to alter objects configuration attributes from defaults. 3) Allow data type and value verification. This is not done today and frequently crops up in FW bug reports. Common Topology Classes ----------------------- Topology today has some common classes that are often reused throughout with slightly altered configurations. i.e. widgets (components), pipelines, dais and controls. Topology2.0 introduces the high level concept of reusable "class" like definition for a AIF_IN/AIF_OUT type object that can be used to create topology objects. Common Topology Attributes -------------------------- Topology defines a lot of attributes per object with different types and constraints. Today there is no easy way to validate type or constraints and this can lead to many hard to find problems in FW at runtime. A new keyword "DefineAttribute" has been added to define attribute type, size, min value, max value, enum_values. This then allows alsatplg to validate each topology object attribute. Topology Classes define the list of attributes that they use and whether the attribute is mandatory, can be overridden by parent users or is immutable. This also helps alsatplg emit the appropriate errors for attribute misuse. Attribute validation ------------------------- One of the main features of Topology2.0 is the ability to add constraints to attributes to define a set of valid values, specify min/max values etc in the class definition. Attribute Inheritance ---------------------- One of the key features of Topology2.0 is howthe attribute values are propagated from a parent object to a child object. This is accomplished by adding attributes/arguments with the same name for a parent and an object. By doing so, when creating a child object, the value for the common attribute is populated from the parent. If the value is provided in the child object instance, then it overrides the value coming from the parent. **ALSA Conf Parser** ---------------- All the changes being proposed and discussed here must be 100% compliant with the ALSA conf parser. i.e. no syntax changes or changes to semantics for any existing keyword. It's intended that there will be NO changes to the ALSA conf parser Request URL : https://github.com/alsa-project/alsa-utils/pull/86 Patch URL : https://github.com/alsa-project/alsa-utils/pull/86.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Re: ASoc / PCM recording-related regression between v5.4 and v5.5
by Hin-Tak Leung 27 Apr '21

27 Apr '21

Hi all, I have come up with a second way of fixing the regression (the first one was a few commits before that): https://github.com/HinTak/seeed-voicecard/commit/19067f3333d7759bdf626e62bc… As far as I understand it, the breakage came from the somewhat unsual design of the SoC device: it has both recording / ADC and a playback / DAC codecs. (a pair of ADC ones, actually) to do real-time echo cancellation / noise filtering applications. The recording codecs use the playback codec's clock; and the playback codec's trigger needs to be called, before the clock can start. I am not entirely happy with the rest of the vendor's code in terms of what code is where of event sequences, but I'll leave that for now. Would appreciate comments, etc.

1 0

[PATCH v2 0/5] ASoC: clock provider clean-up
by Jerome Brunet 27 Apr '21

27 Apr '21

The purpose of this patchset it remove the use the clk member of 'struct clk_hw' in ASoC. 'struct clk' is a per-user reference to an actual clock. In the future, the clk member in 'struct clk_hw' may go away. The usage of this member by a clock provider usually falls into either of following categories: * Mis-usage of the clock consumer API by a clock provider. * Clock provider also being a user of its own clocks. In this case the provider should request a 'struct clk' through the appropriate API instead of poking in 'struct clk_hw' internals. v1 [0] -> v2: * finalize lpass provider move to devm [0]: https://lore.kernel.org/r/20210410111356.467340-1-jbrunet@baylibre.com Jerome Brunet (5): ASoC: stm32: properly get clk from the provider ASoC: wcd934x: use the clock provider API ASoC: rt5682: clock driver must use the clock provider API ASoC: lpass: use the clock provider API ASoC: da7219: properly get clk from the provider sound/soc/codecs/da7219.c | 5 ++++- sound/soc/codecs/lpass-va-macro.c | 7 ++----- sound/soc/codecs/lpass-wsa-macro.c | 11 +++-------- sound/soc/codecs/rt5682.c | 6 +++--- sound/soc/codecs/wcd934x.c | 6 ++++-- sound/soc/stm/stm32_sai_sub.c | 5 ++++- 6 files changed, 20 insertions(+), 20 deletions(-) -- 2.31.1

3 12

[PATCH 1/2] ALSA: pcm: Add support for 705.6KHz and 768KHz sample rate
by Shengjiu Wang 27 Apr '21

27 Apr '21

Some high resolution codecs support 705.6KHz and 768KHz rates. So extend supported sample rate to 768kHz in pcm.h. Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- include/sound/pcm.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index 2e1200d17d0c..88056824ffec 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -121,6 +121,8 @@ struct snd_pcm_ops { #define SNDRV_PCM_RATE_192000 (1<<12) /* 192000Hz */ #define SNDRV_PCM_RATE_352800 (1<<13) /* 352800Hz */ #define SNDRV_PCM_RATE_384000 (1<<14) /* 384000Hz */ +#define SNDRV_PCM_RATE_705600 (1<<15) /* 705600Hz */ +#define SNDRV_PCM_RATE_768000 (1<<16) /* 768000Hz */ #define SNDRV_PCM_RATE_CONTINUOUS (1<<30) /* continuous range */ #define SNDRV_PCM_RATE_KNOT (1<<31) /* supports more non-continuos rates */ @@ -136,6 +138,9 @@ struct snd_pcm_ops { #define SNDRV_PCM_RATE_8000_384000 (SNDRV_PCM_RATE_8000_192000|\ SNDRV_PCM_RATE_352800|\ SNDRV_PCM_RATE_384000) +#define SNDRV_PCM_RATE_8000_768000 (SNDRV_PCM_RATE_8000_768000|\ + SNDRV_PCM_RATE_705600|\ + SNDRV_PCM_RATE_768000) #define _SNDRV_PCM_FMTBIT(fmt) (1ULL << (__force int)SNDRV_PCM_FORMAT_##fmt) #define SNDRV_PCM_FMTBIT_S8 _SNDRV_PCM_FMTBIT(S8) #define SNDRV_PCM_FMTBIT_U8 _SNDRV_PCM_FMTBIT(U8) -- 2.27.0

3 3

ASoC: Serving gpio_desc in codec driver with I2C GPIO expander?
by Pavel Hofman 27 Apr '21

27 Apr '21

Hi, Please is there any reasonable way to use an existing codec driver controlled by gpio_desc (e.g. https://elixir.bootlin.com/linux/v5.12/source/sound/soc/codecs/ak4458.c#L47 ) where the actual pins are provided by outputs of an I2C GPIO expander? I am trying to decide whether to base my setup (ADC + DAC + clock generator + I2S DAI, all controlled via I2C + pins via I2C GPIO expander) purely on ASoC, or whether to keep the ASoC driver minimal (like asoc-simple-card) and do all the I2C settings in userspace as part of the software which writes/reads audio data. It seems the ASoC path is way more complicated as it involves multiple layers of abstractions prone to errors from my side. Thank you very much for your opinion and suggestions. Best regards, Pavel.

1 0

[PATCH] ALSA: virtio: fix kernel-doc
by Pierre-Louis Bossart 27 Apr '21

27 Apr '21

make W=1 warning: sound/virtio/virtio_ctl_msg.c:70: warning: expecting prototype for virtsnd_ctl_msg_request(). Prototype was for virtsnd_ctl_msg_response() instead Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/virtio/virtio_ctl_msg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/virtio/virtio_ctl_msg.c b/sound/virtio/virtio_ctl_msg.c index 26ff7e7cc041..18dc5aca2e0c 100644 --- a/sound/virtio/virtio_ctl_msg.c +++ b/sound/virtio/virtio_ctl_msg.c @@ -61,7 +61,7 @@ void *virtsnd_ctl_msg_request(struct virtio_snd_msg *msg) } /** - * virtsnd_ctl_msg_request() - Get a pointer to the response header. + * virtsnd_ctl_msg_response() - Get a pointer to the response header. * @msg: Control message. * * Context: Any context. -- 2.25.1

2 1

[PATCH 0/7] ASoC: adds new .get_fmt support
by Kuninori Morimoto 27 Apr '21

27 Apr '21

Hi Mark These are a little bit challenging patch-set. We need to set dai_link->dai_fmt to select CPU/Codec settings, and it is selected by Sound Card Driver, today. Because of it, Sound Card user need to know both CPU / Codec available dai_fmt, and needs to select it. For example simple-card / audio-graph case, it is selected by "format" and "bitclock/frame-master/inversion" on DT. But, it can be automatically selected if both CPU and Codec drivers indicate it to ALSA SoC Framework, somehow. If we can use it, Sound Card Driver user no longer need to select it, and I want to use this style on new audio-graph-card2. This patch-set adds new .get_fmt callback which indicate available dai_fmt to ALSA SoC Framework. Of course Sound Card Driver can still select dai_link->dai_fmt, same as before. If Sound Card Driver didn't set it, and if both CPU / Codec had .get_fmt callback, dai_link->dai_fmt will be automatically selected. Kuninori Morimoto (7): ASoC: soc-core: move snd_soc_runtime_set_dai_fmt() to upside ASoC: soc-core: add snd_soc_runtime_get_dai_fmt() ASoC: ak4613: add .get_fmt support ASoC: pcm3168a: add .get_fmt support ASoC: rsnd: add .get_fmt support ASoC: fsi: add .get_fmt support ASoC: hdmi-codec: add .get_fmt support include/sound/soc-dai.h | 35 ++++++ sound/soc/codecs/ak4613.c | 10 ++ sound/soc/codecs/hdmi-codec.c | 19 ++++ sound/soc/codecs/pcm3168a.c | 13 +++ sound/soc/sh/fsi.c | 13 +++ sound/soc/sh/rcar/core.c | 16 +++ sound/soc/soc-core.c | 195 +++++++++++++++++++++++----------- sound/soc/soc-dai.c | 19 ++++ sound/soc/soc-utils.c | 26 +++++ 9 files changed, 284 insertions(+), 62 deletions(-) -- 2.25.1

2 12