December 2020 - Alsa-devel - mailman.alsa-project.org

[PATCH 1/3] ALSA: hda/ca0132 - Fix AE-5 rear headphone pincfg.
by Connor McAdams 10 Dec '20

10 Dec '20

The Windows driver sets the pincfg for the AE-5's rear-headphone to report as a microphone. This causes issues with Pulseaudio mistakenly believing there is no headphone plugged in. In Linux, we should instead set it to be a headphone. Signed-off-by: Connor McAdams <conmanx360(a)gmail.com> --- sound/pci/hda/patch_ca0132.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 4fbec4258f58..e96db73c32f5 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -1223,7 +1223,7 @@ static const struct hda_pintbl ae5_pincfgs[] = { { 0x0e, 0x01c510f0 }, /* SPDIF In */ { 0x0f, 0x01017114 }, /* Port A -- Rear L/R. */ { 0x10, 0x01017012 }, /* Port D -- Center/LFE or FP Hp */ - { 0x11, 0x01a170ff }, /* Port B -- LineMicIn2 / Rear Headphone */ + { 0x11, 0x012170ff }, /* Port B -- LineMicIn2 / Rear Headphone */ { 0x12, 0x01a170f0 }, /* Port C -- LineIn1 */ { 0x13, 0x908700f0 }, /* What U Hear In*/ { 0x18, 0x50d000f0 }, /* N/A */ -- 2.25.1

2 5

[PATCH v2 0/5] ALSA: hda/ca0132 - Fix no-audio issues and add documentation.
by Connor McAdams 10 Dec '20

10 Dec '20

This patch series attempts to fix the no audio at startup issues that have been occurring for some users, using information gained through reverse engineering the ca0132's onboard 8051 processor. The issue of no audio on startup seemed to be caused by two separate problems: not resetting the codec upon initialization, and not making sure the DSP allocates it's DMA channels correctly. Tested and working on all cards, except for the AE-7. The AE-7 shouldn't have any issues, however, I don't have one on hand to test. Connor McAdams (5): ALSA: hda/ca0132 - Reset codec upon initialization. ALSA: hda/ca0132 - Add stream port remapping function. ALSA: hda/ca0132 - Add 8051 exram helper functions. ALSA: hda/ca0132 - Ensure DSP is properly setup post-firmware download. ALSA: hda/ca0132 - Remove now unnecessary DSP setup functions. sound/pci/hda/patch_ca0132.c | 558 ++++++++++++++++++++++------------- 1 file changed, 354 insertions(+), 204 deletions(-) v2 changes: -Remove conditional mutexes from patches 3 and 4. -- 2.25.1

2 6

[RFC] ASoC: max98373: don't access volatile registers in bias level off
by Bard Liao 10 Dec '20

10 Dec '20

We will set regcache_cache_only true in suspend. As a result, regmap_read will return error when we try to read volatile registers in suspend. Besides, it doesn't make sense to read feedback data when codec is not active. To avoid the regmap_read error, this patch try to return a fake value when kcontrol _get is called in suspend. However, the question is what is the "correct" behavior when we try to read a volatile register when cache only is set. 1. return an error code to signal codec is not available as what we have now. 2. return a fake value like what this patch do. 3. wake-up the codec and always return a valid value. Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- sound/soc/codecs/max98373.c | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c index 929bb1798c43..07494e40c296 100644 --- a/sound/soc/codecs/max98373.c +++ b/sound/soc/codecs/max98373.c @@ -168,6 +168,23 @@ static SOC_ENUM_SINGLE_DECL(max98373_adc_samplerate_enum, MAX98373_R2051_MEAS_ADC_SAMPLING_RATE, 0, max98373_ADC_samplerate_text); +static int max98373_feedback_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_component *component = snd_kcontrol_chip(kcontrol); + + if (snd_soc_component_get_bias_level(component) == SND_SOC_BIAS_OFF) { + /* + * We can't get the feedback data when codec is off, set + * value = 0 and return 0 to avoid error. + */ + ucontrol->value.integer.value[0] = 0; + return 0; + } + + return snd_soc_put_volsw(kcontrol, ucontrol); +} + static const struct snd_kcontrol_new max98373_snd_controls[] = { SOC_SINGLE("Digital Vol Sel Switch", MAX98373_R203F_AMP_DSP_CFG, MAX98373_AMP_VOL_SEL_SHIFT, 1, 0), @@ -209,8 +226,10 @@ SOC_SINGLE("ADC PVDD FLT Switch", MAX98373_R2052_MEAS_ADC_PVDD_FLT_CFG, MAX98373_FLT_EN_SHIFT, 1, 0), SOC_SINGLE("ADC TEMP FLT Switch", MAX98373_R2053_MEAS_ADC_THERM_FLT_CFG, MAX98373_FLT_EN_SHIFT, 1, 0), -SOC_SINGLE("ADC PVDD", MAX98373_R2054_MEAS_ADC_PVDD_CH_READBACK, 0, 0xFF, 0), -SOC_SINGLE("ADC TEMP", MAX98373_R2055_MEAS_ADC_THERM_CH_READBACK, 0, 0xFF, 0), +SOC_SINGLE_EXT("ADC PVDD", MAX98373_R2054_MEAS_ADC_PVDD_CH_READBACK, 0, 0xFF, 0, + max98373_feedback_get, NULL), +SOC_SINGLE_EXT("ADC TEMP", MAX98373_R2055_MEAS_ADC_THERM_CH_READBACK, 0, 0xFF, 0, + max98373_feedback_get, NULL), SOC_SINGLE("ADC PVDD FLT Coeff", MAX98373_R2052_MEAS_ADC_PVDD_FLT_CFG, 0, 0x3, 0), SOC_SINGLE("ADC TEMP FLT Coeff", MAX98373_R2053_MEAS_ADC_THERM_FLT_CFG, @@ -226,7 +245,8 @@ SOC_SINGLE("BDE LVL1 Thresh", MAX98373_R2097_BDE_L1_THRESH, 0, 0xFF, 0), SOC_SINGLE("BDE LVL2 Thresh", MAX98373_R2098_BDE_L2_THRESH, 0, 0xFF, 0), SOC_SINGLE("BDE LVL3 Thresh", MAX98373_R2099_BDE_L3_THRESH, 0, 0xFF, 0), SOC_SINGLE("BDE LVL4 Thresh", MAX98373_R209A_BDE_L4_THRESH, 0, 0xFF, 0), -SOC_SINGLE("BDE Active Level", MAX98373_R20B6_BDE_CUR_STATE_READBACK, 0, 8, 0), +SOC_SINGLE_EXT("BDE Active Level", MAX98373_R20B6_BDE_CUR_STATE_READBACK, 0, 8, 0, + max98373_feedback_get, NULL), SOC_SINGLE("BDE Clip Mode Switch", MAX98373_R2092_BDE_CLIPPER_MODE, 0, 1, 0), SOC_SINGLE("BDE Thresh Hysteresis", MAX98373_R209B_BDE_THRESH_HYST, 0, 0xFF, 0), SOC_SINGLE("BDE Hold Time", MAX98373_R2090_BDE_LVL_HOLD, 0, 0xFF, 0), -- 2.17.1

5 7

AMD ACP raven ridge: invalid audio mode 2
by Janpieter Sollie 10 Dec '20

10 Dec '20

Forwarded from: https://bugzilla.kernel.org/show_bug.cgi?id=208699 Anybody who knows what this "ACP" actually does? what's its use? Kind regards, Janpieter Sollie

3 6

[PATCH 1/2] ASoC: Intel: common: add ACPI matching tables for Alder Lake
by Kai Vehmanen 09 Dec '20

09 Dec '20

Initial support for ADL w/ RT711 Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- include/sound/soc-acpi-intel-match.h | 2 + sound/soc/intel/common/Makefile | 2 +- .../intel/common/soc-acpi-intel-adl-match.c | 52 +++++++++++++++++++ 3 files changed, 55 insertions(+), 1 deletion(-) create mode 100644 sound/soc/intel/common/soc-acpi-intel-adl-match.c diff --git a/include/sound/soc-acpi-intel-match.h b/include/sound/soc-acpi-intel-match.h index 5c49e7d78002..59551b1f22f3 100644 --- a/include/sound/soc-acpi-intel-match.h +++ b/include/sound/soc-acpi-intel-match.h @@ -29,12 +29,14 @@ extern struct snd_soc_acpi_mach snd_soc_acpi_intel_icl_machines[]; extern struct snd_soc_acpi_mach snd_soc_acpi_intel_tgl_machines[]; extern struct snd_soc_acpi_mach snd_soc_acpi_intel_ehl_machines[]; extern struct snd_soc_acpi_mach snd_soc_acpi_intel_jsl_machines[]; +extern struct snd_soc_acpi_mach snd_soc_acpi_intel_adl_machines[]; extern struct snd_soc_acpi_mach snd_soc_acpi_intel_cnl_sdw_machines[]; extern struct snd_soc_acpi_mach snd_soc_acpi_intel_cfl_sdw_machines[]; extern struct snd_soc_acpi_mach snd_soc_acpi_intel_cml_sdw_machines[]; extern struct snd_soc_acpi_mach snd_soc_acpi_intel_icl_sdw_machines[]; extern struct snd_soc_acpi_mach snd_soc_acpi_intel_tgl_sdw_machines[]; +extern struct snd_soc_acpi_mach snd_soc_acpi_intel_adl_sdw_machines[]; /* * generic table used for HDA codec-based platforms, possibly with diff --git a/sound/soc/intel/common/Makefile b/sound/soc/intel/common/Makefile index 64468fe9c513..12a205ccdeeb 100644 --- a/sound/soc/intel/common/Makefile +++ b/sound/soc/intel/common/Makefile @@ -8,7 +8,7 @@ snd-soc-acpi-intel-match-objs := soc-acpi-intel-byt-match.o soc-acpi-intel-cht-m soc-acpi-intel-cnl-match.o soc-acpi-intel-cfl-match.o \ soc-acpi-intel-cml-match.o soc-acpi-intel-icl-match.o \ soc-acpi-intel-tgl-match.o soc-acpi-intel-ehl-match.o \ - soc-acpi-intel-jsl-match.o \ + soc-acpi-intel-jsl-match.o soc-acpi-intel-adl-match.o \ soc-acpi-intel-hda-match.o obj-$(CONFIG_SND_SOC_INTEL_SST) += snd-soc-sst-dsp.o snd-soc-sst-ipc.o diff --git a/sound/soc/intel/common/soc-acpi-intel-adl-match.c b/sound/soc/intel/common/soc-acpi-intel-adl-match.c new file mode 100644 index 000000000000..06b233d63b73 --- /dev/null +++ b/sound/soc/intel/common/soc-acpi-intel-adl-match.c @@ -0,0 +1,52 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * soc-apci-intel-adl-match.c - tables and support for ADL ACPI enumeration. + * + * Copyright (c) 2020, Intel Corporation. + */ + +#include <sound/soc-acpi.h> +#include <sound/soc-acpi-intel-match.h> + +static const struct snd_soc_acpi_endpoint single_endpoint = { + .num = 0, + .aggregated = 0, + .group_position = 0, + .group_id = 0, +}; + +static const struct snd_soc_acpi_adr_device rt711_0_adr[] = { + { + .adr = 0x000020025D071100, + .num_endpoints = 1, + .endpoints = &single_endpoint, + .name_prefix = "rt711" + } +}; + +static const struct snd_soc_acpi_link_adr adl_rvp[] = { + { + .mask = BIT(0), + .num_adr = ARRAY_SIZE(rt711_0_adr), + .adr_d = rt711_0_adr, + }, + {} +}; + +struct snd_soc_acpi_mach snd_soc_acpi_intel_adl_machines[] = { + {}, +}; +EXPORT_SYMBOL_GPL(snd_soc_acpi_intel_adl_machines); + +/* this table is used when there is no I2S codec present */ +struct snd_soc_acpi_mach snd_soc_acpi_intel_adl_sdw_machines[] = { + { + .link_mask = 0x1, /* link0 required */ + .links = adl_rvp, + .drv_name = "sof_sdw", + .sof_fw_filename = "sof-adl.ri", + .sof_tplg_filename = "sof-adl-rt711.tplg", + }, + {}, +}; +EXPORT_SYMBOL_GPL(snd_soc_acpi_intel_adl_sdw_machines); -- 2.28.0

2 2

[bug report] ASoC: topology: fix endianness issues
by Dan Carpenter 09 Dec '20

09 Dec '20

[ This bug is way older than your patch but you might know the answer. -dan ] Hello Pierre-Louis Bossart, The patch 5aebe7c7f9c2: "ASoC: topology: fix endianness issues" from Apr 4, 2019, leads to the following static checker warning: sound/soc/soc-topology.c:903 soc_tplg_denum_create_values() warn: potential pointer math issue ('se->dobj.control.dvalues' is a 64 bit pointer) sound/soc/soc-topology.c 887 static int soc_tplg_denum_create_values(struct soc_tplg *tplg, struct soc_enum *se, 888 struct snd_soc_tplg_enum_control *ec) 889 { 890 int i; 891 892 if (le32_to_cpu(ec->items) > sizeof(*ec->values)) The warning is from this line where Smatch starts to think that "ec->items" is the number of bytes, but later in the function we treat it was the number of elements. I do think probably this should be if: if (le32_to_cpu(ec->items) > ARRAY_SIZE(ec->values)) return -EINVAL; The ec->values[] is an array of u32: __le32 values[SND_SOC_TPLG_NUM_TEXTS * SNDRV_CTL_ELEM_ID_NAME_MAXLEN / 4]; so this code will return -EINVAL for anything larger than 4. Changing it to ARRAY_SIZE() would raise the limit to 176. 893 return -EINVAL; 894 895 se->dobj.control.dvalues = devm_kzalloc(tplg->dev, le32_to_cpu(ec->items) * 896 sizeof(u32), 897 GFP_KERNEL); 898 if (!se->dobj.control.dvalues) 899 return -ENOMEM; 900 901 /* convert from little-endian */ 902 for (i = 0; i < le32_to_cpu(ec->items); i++) { 903 se->dobj.control.dvalues[i] = le32_to_cpu(ec->values[i]); 904 } 905 906 return 0; 907 } regards, dan carpenter

4 4

[PATCH alsa-utils] alsa-info: Add lsusb and stream outputs
by Takashi Iwai 09 Dec '20

09 Dec '20

We need more detailed information for USB-audio devices, at least the lsusb -v output and the contents of stream* proc files. Let's add them to alsa-info.sh output. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- alsa-info/alsa-info.sh | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/alsa-info/alsa-info.sh b/alsa-info/alsa-info.sh index f179bfab8655..3871b97a2268 100755 --- a/alsa-info/alsa-info.sh +++ b/alsa-info/alsa-info.sh @@ -476,6 +476,18 @@ cat /proc/asound/card*/codec\#* > $TEMPDIR/alsa-hda-intel.tmp 2> /dev/null cat /proc/asound/card*/codec97\#0/ac97\#0-0 > $TEMPDIR/alsa-ac97.tmp 2> /dev/null cat /proc/asound/card*/codec97\#0/ac97\#0-0+regs > $TEMPDIR/alsa-ac97-regs.tmp 2> /dev/null +#Check for USB descriptors +if [ -x /usr/bin/lsusb ]; then + for f in /proc/asound/card[0-9]*/usbbus; do + test -f "$f" || continue + id=$(sed 's@/@:@' $f) + lsusb -v -s $id >> $TEMPDIR/lsusb.tmp 2> /dev/null + done +fi + +#Check for USB stream setup +cat /proc/asound/card*/stream[0-9]* > $TEMPDIR/alsa-usbstream.tmp 2> /dev/null + #Check for USB mixer setup cat /proc/asound/card*/usbmixer > $TEMPDIR/alsa-usbmixer.tmp 2> /dev/null @@ -649,6 +661,27 @@ if [ -s "$TEMPDIR/alsa-ac97.tmp" ]; then echo "" >> $FILE fi +if [ -s "$TEMPDIR/lsusb.tmp" ]; then + echo "!!USB Descriptors" >> $FILE + echo "!!---------------" >> $FILE + echo "--startcollapse--" >> $FILE + cat $TEMPDIR/lsusb.tmp >> $FILE + echo "--endcollapse--" >> $FILE + echo "" >> $FILE + echo "" >> $FILE +fi + +if [ -s "$TEMPDIR/lsusb.tmp" ]; then + echo "!!USB Stream information" >> $FILE + echo "!!----------------------" >> $FILE + echo "--startcollapse--" >> $FILE + echo "" >> $FILE + cat $TEMPDIR/alsa-usbstream.tmp >> $FILE + echo "--endcollapse--" >> $FILE + echo "" >> $FILE + echo "" >> $FILE +fi + if [ -s "$TEMPDIR/alsa-usbmixer.tmp" ]; then echo "!!USB Mixer information" >> $FILE echo "!!---------------------" >> $FILE -- 2.26.2

1 0

[PATCH] ALSA: usb-audio: Add implicit fb support for Steinberg UR22
by Takashi Iwai 09 Dec '20

09 Dec '20

Steinberg UR22 (with USB ID 0499:1509) requires the implicit feedback for the proper playback, otherwise it causes occasional cracks. This patch adds the corresponding the quirk table entry with the recently added generic implicit fb support. Reported-and-tested-by: Kilian <meschi(a)posteo.de> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/usb/implicit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/usb/implicit.c b/sound/usb/implicit.c index 386198b36b87..4e911d200562 100644 --- a/sound/usb/implicit.c +++ b/sound/usb/implicit.c @@ -42,6 +42,7 @@ struct snd_usb_implicit_fb_match { /* Implicit feedback quirk table for playback */ static const struct snd_usb_implicit_fb_match playback_implicit_fb_quirks[] = { /* Generic matching */ + IMPLICIT_FB_GENERIC_DEV(0x0499, 0x1509), /* Steinberg UR22 */ IMPLICIT_FB_GENERIC_DEV(0x0763, 0x2080), /* M-Audio FastTrack Ultra */ IMPLICIT_FB_GENERIC_DEV(0x0763, 0x2081), /* M-Audio FastTrack Ultra */ IMPLICIT_FB_GENERIC_DEV(0x0763, 0x2030), /* M-Audio Fast Track C400 */ -- 2.26.2

1 0

Steinberg UR22 Crackling and Clicks
by meschi＠posteo.de 09 Dec '20

09 Dec '20

Hi, I am using a Steinberg UR22 audio interface. Since installing Ubuntu 20.04 on my workstation I have slight crackling in audio playback. It doesn't matter if the audio gets routed through pulse, jack or played straight to alsa. When running jack, the crackling is not showing any xruns. It's not possible to get any glitch-free playback in the system. The onboard intel audio works fine. My system: alsa info: alsa-project.org/db/?f=8b821b17a8c83fa5db866f34a5b4dfe74d640a32 Processor: Intel Xeon X5687 $ uname -a Linux WorkStation-T5500 5.4.0-56-lowlatency #62-Ubuntu SMP PREEMPT Mon Nov 23 20:19:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux I have tried: 5.4.0-56-generic and -lowlatency 5.8.0-31-generic and -lowlatency setting cpu governor to performance using nouveau driver over nvidia When playing a file with aplay like this: systemctl --user stop pulseaudio.socket systemctl --user stop pulseaudio.service aplay -D plughw:CARD=UR22 ./test.wav slight crackling can be heard every 5-10 seconds. It also appears, that the clicks heard are not always on both channels, sometimes the left stereo channel clicks, sometimes the right, sometimes both. Plugging the Interface into different USB-ports doesn't help. The only external devices connected via USB are my mouse and my keyboard. On Wndows the same setup on the same machine works fine. To make things even weirder, using the same audio interface on my Thinkpad x220 (Core i5-2540M) with ubuntu 20.04 and 5.4.0.56-lowlatency does not show this problem. Running dmesg seems to show nothing audio driver related after: [ 22.425520] usbcore: registered new interface driver snd-usb-audio I have found a similar issue showcasing the problem on manjaro with a differend soundcard. Therefore I suspect the problem is caused by ALSA interacting with the hardware. https://forum.manjaro.org/t/pops-clicks-on-audio-interface/40129 Here is another occurence on ubuntu on yet another audio interface. https://askubuntu.com/questions/1256787/ubuntu-2004-novation-xiosynth-exter… If I can supply more information I'm happy to help. I couldn't find a similar issue in this mailing list, so if this is already fixed I apologize in advance. Kilian

3 15

[PATCH] ASoC: rt1015: check the return value of regmap_read during i2c probe
by derek.fang＠realtek.com 09 Dec '20

09 Dec '20

From: Derek Fang <derek.fang(a)realtek.com> In some projects, the device ID register is not read correctly. This patch helps to verify the issue is caused from i2c host or client. Signed-off-by: Derek Fang <derek.fang(a)realtek.com> diff --git a/sound/soc/codecs/rt1015.c b/sound/soc/codecs/rt1015.c index ac4c9f43b338..32e6bcf763d1 100644 --- a/sound/soc/codecs/rt1015.c +++ b/sound/soc/codecs/rt1015.c @@ -1207,8 +1207,13 @@ static int rt1015_i2c_probe(struct i2c_client *i2c, rt1015->hw_config = (i2c->addr == 0x29) ? RT1015_HW_29 : RT1015_HW_28; - regmap_read(rt1015->regmap, RT1015_DEVICE_ID, &val); - if ((val != RT1015_DEVICE_ID_VAL) && (val != RT1015_DEVICE_ID_VAL2)) { + ret = regmap_read(rt1015->regmap, RT1015_DEVICE_ID, &val); + if (ret) { + dev_err(&i2c->dev, + "Failed to read device register: %d\n", ret); + return ret; + } else if ((val != RT1015_DEVICE_ID_VAL) && + (val != RT1015_DEVICE_ID_VAL2)) { dev_err(&i2c->dev, "Device with ID register %x is not rt1015\n", val); return -ENODEV; -- 2.17.1

2 1