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

kbl-r5514-5663-max Headphone does not work
by GitHub issues - opened 23 Jul '21

23 Jul '21

alsa-project/alsa-ucm-conf issue #108 was opened from jmontleon: On a Pixelbook I have copied these firmware files in place: - /opt/google/dsm/dsmparam.bin - /lib/firmware/9d71-GOOGLE-EVEMAX-0-tplg.bin - /lib/firmware/dsp_lib_dsm_core_spt_release.bin - /lib/firmware/intel/dsp_fw_C75061F3-F2B2-4DCC-8F9F-82ABB4131E66.bin With that alone the speakers started working after a reboot. I have been trying to modify the ucm HiFi.conf to ucm2 on Fedora. If I comment out all of `SectionDevice."Headphones"` the speakers and internal microphone work. If I leave it I see a bunch of error messages in dmesg. Pulseaudio also produces some error messages and then just loads a dummy device. dmesg: ``` [ 7866.107942] Kbl Audio Headset Playback: ASoC: no backend DAIs enabled for Kbl Audio Headset Playback [ 7866.107950] Kbl Audio Headset Playback: ASoC: dpcm_fe_dai_prepare() failed (-22) ``` pulseaudio: ``` D: [pulseaudio] alsa-util.c: Maximum hw buffer size is 21845 ms I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22) I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22) I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22) I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22) D: [pulseaudio] alsa-util.c: Set neither period nor buffer size. I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22) I: [pulseaudio] alsa-util.c: snd_pcm_hw_params failed: Invalid argument D: [pulseaudio] alsa-util.c: Trying plug:_ucm0006.hw:kblr55145663max,2 with SND_PCM_NO_AUTO_FORMAT ... I: [pulseaudio] (alsa-lib)conf.c: Unknown parameter 1 I: [pulseaudio] (alsa-lib)conf.c: Parse arguments error: No such file or directory I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM plug:_ucm0006.hw:kblr55145663max,2 I: [pulseaudio] alsa-util.c: Error opening PCM device plug:_ucm0006.hw:kblr55145663max,2: No such file or directory D: [pulseaudio] alsa-mixer.c: Profile set 0x555cededf730, auto_profiles=no, probed=yes, n_mappings=0, n_profiles=0, n_decibel_fixes=0 E: [pulseaudio] module-alsa-card.c: Failed to find a working profile. E: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="0" name="platform-kbl_r5514_5663_max" card_name="alsa_card.platform-kbl_r5514_5663_max" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1""): initialization failed. I: [pulseaudio] module-udev-detect.c: Card /devices/platform/kbl_r5514_5663_max/sound/card0 (alsa_card.platform-kbl_r5514_5663_max) failed to load module. ``` >From reading I gather there's probably some routing incorrectly or incompletely set up that is the cause, but I'm at a bit of a loss on where to go from here. I saw a suggestion somewhere to set this module option, but as far as I can tell it makes no difference: ``` cat /etc/modprobe.d/dsp.conf options snd_intel_dspcfg dsp_driver=2 ``` Not really an alsa / ucm problem as far as I am aware but in the interest of giving as much info as possible I originally switched to pulseaudio because I had an easier time finding meaningful logs. I switched back to pipewire later to realize the mic is just producing awful noise so I went back to pulseaudio for the time being. Might need to file a pipewire bug later. The HiFi.conf and alsa-info are attached. [alsa-info.txt](https://github.com/alsa-project/alsa-ucm-conf/files/6870590/… [Hifi.conf.txt](https://github.com/alsa-project/alsa-ucm-conf/files/6870593/… Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/108 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v3 1/2] ASoC: amd: Don't show messages about deferred probing by default
by Mario Limonciello 23 Jul '21

23 Jul '21

Nearly every boot with a Lenovo P14s is showing acp_pdm_mach acp_pdm_mach.0: snd_soc_register_card(acp) failed: -517 This isn't useful to a user, especially as probing will run again. Use the dev_err_probe helper to hide the deferrerd probing messages. CC: markpearson(a)lenovo.com Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- sound/soc/amd/renoir/acp3x-rn.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) v1->v2: * Adjust return codes v2->v3: * Use deferred probing helper * Rebase on asoc-next/for-5.15 diff --git a/sound/soc/amd/renoir/acp3x-rn.c b/sound/soc/amd/renoir/acp3x-rn.c index 306134b89a82..5d979a7b77fb 100644 --- a/sound/soc/amd/renoir/acp3x-rn.c +++ b/sound/soc/amd/renoir/acp3x-rn.c @@ -54,10 +54,9 @@ static int acp_probe(struct platform_device *pdev) snd_soc_card_set_drvdata(card, machine); ret = devm_snd_soc_register_card(&pdev->dev, card); if (ret) { - dev_err(&pdev->dev, - "snd_soc_register_card(%s) failed: %d\n", - acp_card.name, ret); - return ret; + return dev_err_probe(&pdev->dev, ret, + "snd_soc_register_card(%s) failed\n", + card->name); } return 0; } -- 2.25.1

3 5

tlv320aic3x audio driver -- possible bug
by Frederick Gotham 23 Jul '21

23 Jul '21

In the C source file "tlv320aic3x" in the function "aic3x_set_power", when the argument for power is 0, the hardware registers are saved to the Linux computer as follows: regcache_cache_only(aic3x->regmap, true); And then later when "aic3x_set_power" is called with power set to 1, the previous values are then restored back to their hardware registers: regcache_cache_only(aic3x->regmap, false); regcache_sync(aic3x->regmap); When the device is powered back on, the previous setting for microphone bias (MICBIAS) is lost. If it was previously set to 2 volts or 2.5 volts, then when it's powered back on it becomes Off. I'm not very familiar with audio codec chips and how they work, but I think maybe the order of function calls in the "else" branch might be incorrect. Right now the code looks like this: /* * Do soft reset to this codec instance in order to clear * possible VDD leakage currents in case the supply regulators * remain on */ snd_soc_component_write(component, AIC3X_RESET, SOFT_RESET); regcache_mark_dirty(aic3x->regmap); aic3x->power = 0; /* HW writes are needless when bias is off */ regcache_cache_only(aic3x->regmap, true); ret = regulator_bulk_disable(ARRAY_SIZE(aic3x->supplies), aic3x->supplies); However I think that the call to "regcache_cache_only" should come before the soft reset takeS place. The setting for MICBIAS is lost at this line: snd_soc_component_write(component, AIC3X_RESET, SOFT_RESET); And so I think that the call to "regcache_cache_only" should be moved up above "snd_soc_component_write", as follows: /* * Do soft reset to this codec instance in order to clear * possible VDD leakage currents in case the supply regulators * remain on */ regcache_cache_only(aic3x->regmap, true); snd_soc_component_write(component, AIC3X_RESET, SOFT_RESET); regcache_mark_dirty(aic3x->regmap); aic3x->power = 0; ret = regulator_bulk_disable(ARRAY_SIZE(aic3x->supplies), aic3x->supplies);

2 1

[PATCH 0/6] soundwire/ASoC: abstract platform-dependent bases
by Bard Liao 23 Jul '21

23 Jul '21

shim base and alh base are platform-dependent. This series suggests to use variables for those bases. It allows us to use different bases for new platforms. Bard Liao (6): soundwire: move intel sdw register definitions to sdw_intel.h ASoC: SOF: intel: add sdw_shim/alh_base to sof_intel_dsp_desc ASoC: SOF: intel: hda: remove HDA_DSP_REG_SNDW_WAKE_STS definition ASoC: SOF: intel: move sof_intel_dsp_desc() forward ASoC: SOF: intel: add snd_sof_dsp_check_sdw_irq ops soundwire: intel: introduce shim and alh base drivers/soundwire/intel.c | 74 ------------------------ drivers/soundwire/intel_init.c | 14 ++--- include/linux/soundwire/sdw_intel.h | 87 +++++++++++++++++++++++++++++ sound/soc/sof/intel/cnl.c | 6 ++ sound/soc/sof/intel/hda.c | 39 ++++++++----- sound/soc/sof/intel/hda.h | 8 ++- sound/soc/sof/intel/icl.c | 3 + sound/soc/sof/intel/shim.h | 3 + sound/soc/sof/intel/tgl.c | 12 ++++ 9 files changed, 149 insertions(+), 97 deletions(-) -- 2.17.1

3 8

[PATCH 0/2] ASoC/soundwire: add quirks for Intel 'Bishop County' NUC M15
by Pierre-Louis Bossart 23 Jul '21

23 Jul '21

The 'Bishop County' NUC Laptops designed by Intel rely on SoundWire peripherals. Quirks are required on the soundwire/ side to work-around ACPI issues (bad _ADR) and sound/soc/ side for jack detection. The two patches are independent and can be merged in the two subsystem independently if desired. Both patches are however required in any backport. Thanks to Gilles van Eeden for reporting this issue and testing these patches. Pierre-Louis Bossart (2): soundwire: dmi-quirks: add quirk for Intel 'Bishop County' NUC M15 ASOC: Intel: sof_sdw: add quirk for Intel 'Bishop County' NUC M15 drivers/soundwire/dmi-quirks.c | 16 ++++++++++++---- sound/soc/intel/boards/sof_sdw.c | 11 +++++++++++ 2 files changed, 23 insertions(+), 4 deletions(-) -- 2.25.1

3 8

sof-hda-dsp: Set Capture Switch on in the BootSequence
by GitHub pull_request - opened 23 Jul '21

23 Jul '21

alsa-project/alsa-ucm-conf pull request #107 was opened from jason77-wang: We found an issue that the PA source of Mic2/Headset and Mic2 is muted by default after newly install an OS, the root cause is the 'Capture Switch' is set to off in the kernel. Without ucm, the /usr/share/alsa/init/default will set the 'Capture Switch' to on, similarly we set it to on in the BootSequence of ucm. Signed-off-by: Hui Wang <hui.wang(a)canonical.com> Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/107 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/107.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ASRock (A320M-HDV R4.0) No analog audio driver detected -
by GitHub issues - opened 22 Jul '21

22 Jul '21

alsa-project/alsa-lib issue #165 was opened from PedePanoOriginal: Hello guys! I just got a new PC and I was so happy about it. It's a Ryzen 5 - 3600, GeForce GT 1030 GPU, the motherboard is a ASRock A320M-HDV R4.0. The first thing I did when I pluged it in was installing Pop!_OS 20.04 LTS. Everything worked fine except my audio analog ports. They are simply not detected by OS, the only output audio device detected is "GP108 High Definition Audio Controller Digital Stereo". I've done a lot of googling, tried everything I could find, but, no success. I noticed that when I turn on the PC a message is displayed, something like that: "snd_hda_intel 0000:23:00.4: no codecs found". This message disappear if I turn off onboard audio stuff at the bios. I would love some help if possible. I'm a linux noob, so I'm sorry to not be able to provide better information now but, I can do it later with some help. Issue URL : https://github.com/alsa-project/alsa-lib/issues/165 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ASoC: codecs: wcd938x: fix wcd module dependency
by Arnd Bergmann 22 Jul '21

22 Jul '21

From: Arnd Bergmann <arnd(a)arndb.de> With SND_SOC_ALL_CODECS=y and SND_SOC_WCD938X_SDW=m, there is a link error from a reverse dependency, since the built-in codec driver calls into the modular soundwire back-end: x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_codec_free': wcd938x.c:(.text+0x2c0): undefined reference to `wcd938x_sdw_free' x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_codec_hw_params': wcd938x.c:(.text+0x2f6): undefined reference to `wcd938x_sdw_hw_params' x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_codec_set_sdw_stream': wcd938x.c:(.text+0x332): undefined reference to `wcd938x_sdw_set_sdw_stream' x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_tx_swr_ctrl': wcd938x.c:(.text+0x23de): undefined reference to `wcd938x_swr_get_current_bank' x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_bind': wcd938x.c:(.text+0x2579): undefined reference to `wcd938x_sdw_device_get' x86_64-linux-ld: wcd938x.c:(.text+0x25a1): undefined reference to `wcd938x_sdw_device_get' x86_64-linux-ld: wcd938x.c:(.text+0x262a): undefined reference to `__devm_regmap_init_sdw' Work around this using two small hacks: An added Kconfig dependency prevents the main driver from being built-in when soundwire support itself is a loadable module to allow calling devm_regmap_init_sdw(), and a Makefile trick links the wcd938x-sdw backend as built-in if needed to solve the dependency between the two modules. Fixes: 045442228868 ("ASoC: codecs: wcd938x: add audio routing and Kconfig") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- I saw this on -rc2, please ignore if this is already fixed --- sound/soc/codecs/Kconfig | 1 + sound/soc/codecs/Makefile | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 7ebae3f09435..459deba31485 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -1558,6 +1558,7 @@ config SND_SOC_WCD934X config SND_SOC_WCD938X tristate + depends on SOUNDWIRE || !SOUNDWIRE config SND_SOC_WCD938X_SDW tristate "WCD9380/WCD9385 Codec - SDW" diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index de8b83dd2c76..7bb38c370842 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -583,7 +583,10 @@ obj-$(CONFIG_SND_SOC_WCD_MBHC) += snd-soc-wcd-mbhc.o obj-$(CONFIG_SND_SOC_WCD9335) += snd-soc-wcd9335.o obj-$(CONFIG_SND_SOC_WCD934X) += snd-soc-wcd934x.o obj-$(CONFIG_SND_SOC_WCD938X) += snd-soc-wcd938x.o -obj-$(CONFIG_SND_SOC_WCD938X_SDW) += snd-soc-wcd938x-sdw.o +ifdef CONFIG_SND_SOC_WCD938X_SDW +# avoid link failure by forcing sdw code built-in when needed +obj-$(CONFIG_SND_SOC_WCD938X) += snd-soc-wcd938x-sdw.o +endif obj-$(CONFIG_SND_SOC_WL1273) += snd-soc-wl1273.o obj-$(CONFIG_SND_SOC_WM0010) += snd-soc-wm0010.o obj-$(CONFIG_SND_SOC_WM1250_EV1) += snd-soc-wm1250-ev1.o -- 2.29.2

2 1

[PATCH] ASoC: tlv320aic32x4: Fix TAS2505/TAS2521 processing block selection
by Marek Vasut 22 Jul '21

22 Jul '21

The TAS2505/TAS2521 does support only three processing block options, unlike TLV320AIC32x4 which supports 25. This is documented in TI slau472 2.5.1.2 Processing Blocks and Page 0 / Register 60: DAC Instruction Set - 0x00 / 0x3C. Limit the Processing Blocks maximum value to 3 on TAS2505/TAS2521 and select processing block PRB_P1 always, because for the configuration of teh codec implemented in this driver, this is the best quality option. Fixes: b4525b6196cd7 ("ASoC: tlv320aic32x4: add support for TAS2505") Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Claudius Heine <ch(a)denx.de> Cc: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/tlv320aic32x4.c | 33 +++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index c51267ce67cf..4d80879dd144 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -682,11 +682,20 @@ static int aic32x4_set_dosr(struct snd_soc_component *component, u16 dosr) static int aic32x4_set_processing_blocks(struct snd_soc_component *component, u8 r_block, u8 p_block) { - if (r_block > 18 || p_block > 25) - return -EINVAL; + struct aic32x4_priv *aic32x4 = snd_soc_component_get_drvdata(component); + + if (aic32x4->type == AIC32X4_TYPE_TAS2505) { + if (r_block || p_block > 3) + return -EINVAL; - snd_soc_component_write(component, AIC32X4_ADCSPB, r_block); - snd_soc_component_write(component, AIC32X4_DACSPB, p_block); + snd_soc_component_write(component, AIC32X4_DACSPB, p_block); + } else { /* AIC32x4 */ + if (r_block > 18 || p_block > 25) + return -EINVAL; + + snd_soc_component_write(component, AIC32X4_ADCSPB, r_block); + snd_soc_component_write(component, AIC32X4_DACSPB, p_block); + } return 0; } @@ -695,6 +704,7 @@ static int aic32x4_setup_clocks(struct snd_soc_component *component, unsigned int sample_rate, unsigned int channels, unsigned int bit_depth) { + struct aic32x4_priv *aic32x4 = snd_soc_component_get_drvdata(component); u8 aosr; u16 dosr; u8 adc_resource_class, dac_resource_class; @@ -721,19 +731,28 @@ static int aic32x4_setup_clocks(struct snd_soc_component *component, adc_resource_class = 6; dac_resource_class = 8; dosr_increment = 8; - aic32x4_set_processing_blocks(component, 1, 1); + if (aic32x4->type == AIC32X4_TYPE_TAS2505) + aic32x4_set_processing_blocks(component, 0, 1); + else + aic32x4_set_processing_blocks(component, 1, 1); } else if (sample_rate <= 96000) { aosr = 64; adc_resource_class = 6; dac_resource_class = 8; dosr_increment = 4; - aic32x4_set_processing_blocks(component, 1, 9); + if (aic32x4->type == AIC32X4_TYPE_TAS2505) + aic32x4_set_processing_blocks(component, 0, 1); + else + aic32x4_set_processing_blocks(component, 1, 9); } else if (sample_rate == 192000) { aosr = 32; adc_resource_class = 3; dac_resource_class = 4; dosr_increment = 2; - aic32x4_set_processing_blocks(component, 13, 19); + if (aic32x4->type == AIC32X4_TYPE_TAS2505) + aic32x4_set_processing_blocks(component, 0, 1); + else + aic32x4_set_processing_blocks(component, 13, 19); } else { dev_err(component->dev, "Sampling rate not supported\n"); return -EINVAL; -- 2.30.2

2 1

[PATCH] ASoC: rt5682: Adjust headset volume button threshold
by derek.fang＠realtek.com 22 Jul '21

22 Jul '21

From: Derek Fang <derek.fang(a)realtek.com> Adjust the threshold of headset button volume+ to fix the wrong button detection issue with some brand headsets. Signed-off-by: Derek Fang <derek.fang(a)realtek.com> diff --git a/sound/soc/codecs/rt5682.c b/sound/soc/codecs/rt5682.c index abcd6f483788..51ecaa2abcd1 100644 --- a/sound/soc/codecs/rt5682.c +++ b/sound/soc/codecs/rt5682.c @@ -44,6 +44,7 @@ static const struct reg_sequence patch_list[] = { {RT5682_I2C_CTRL, 0x000f}, {RT5682_PLL2_INTERNAL, 0x8266}, {RT5682_SAR_IL_CMD_3, 0x8365}, + {RT5682_SAR_IL_CMD_6, 0x0180}, }; void rt5682_apply_patch_list(struct rt5682_priv *rt5682, struct device *dev) -- 2.17.1

2 1