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

Re: [PATCH] ALSA: hda: Skip creating captures in SOF context
by Kai-Heng Feng 06 Jan '23

06 Jan '23

On Mon, Aug 15, 2022 at 3:55 PM Kai-Heng Feng <kai.heng.feng(a)canonical.com> wrote: > > On Wed, Jul 20, 2022 at 9:31 PM Pierre-Louis Bossart > <pierre-louis.bossart(a)linux.intel.com> wrote: > > > > > > > > On 7/20/22 02:52, Jaroslav Kysela wrote: > > > Dne 20. 07. 22 v 3:45 Kai-Heng Feng napsal(a): > > >> On Tue, Jul 19, 2022 at 11:41 PM Jaroslav Kysela <perex(a)perex.cz> wrote: > > >>> > > >>> Dne 19. 07. 22 v 16:47 Kai-Heng Feng napsal(a): > > >>>> On HP laptops that use SOF driver for DMIC, the micmute LED doesn't > > >>>> light up when mic is muted after commit 9b014266ef8a ("ASoC: SOF: > > >>>> topology: use new sound control LED layer"). > > >>>> > > >>>> The micmute LED itself is still working via sysfs, but it doesn't follow > > >>>> mute anymore. That's because unlike vendors like Dell and Lenovo, HP > > >>>> laptops use HDA codec to control mute LEDs instead of ACPI. So on HP > > >>>> laptops, both SOF and HDA create captures with > > >>>> SNDRV_CTL_ELEM_ACCESS_MIC_LED access, snd_ctl_led_set_state() considers > > >>>> there are two different kcontrols and one of them is not muted. > > >>> > > >>> It does not mean that it's a wrong behavior. When both controls are muted, the > > >>> LED should be turned on. It just requires that all inputs are off (and it may > > >>> be the default - probably we can set in UCM or so). If you turn the "Capture > > >>> Switch" off in amixer / alsamixer, do things work as expected ? > > >> > > >> Yes. When all captures are muted the micmute LED is on. > > >> > > >>> > > >>>> So skip creating captures for HDA when it's called from SOF, the > > >>>> captures are already handled by SOF. > > >>> > > >>> The capture controls are for other inputs like external analog microphone. If > > >>> it is required to suppress the MIC LED for some hardware, just skip the > > >>> "spec->mic_mute_led = 1" assignment in hda_generic.c . Also, the check > > >>> "codec->core.type != HDA_DEV_ASOC" is not sufficient, because you don't know, > > >>> if the topology really sets the MIC LED flag. > > >> > > >> AFAIK the external analog microphone on DMIC laptop is driven by SOF driver too. > > >> If those capture controls are indeed needed for external analog mics, > > >> use UCM to mute them by default won't work either. > > > > > > Could you describe this ? I though that only DMIC is handled by SOF when HDA > > > codec is in the system. There is a separate analog codec for external analog > > > microphone or the HDA codec is somehow connected to SOF/DSP ? If so, how ? > > > > The HDA codec is connected in the same way in all cases, there's no > > hardware/electrical/routing difference. > > > > When used, the SOF driver will handle ALL links, be they DMIC or > > HDAudio. The difference for HDaudio is that instead of a single DMA > > transfer (DDR->FIFO), we have a first 'Host' DMA into the DSP SRAM, some > > processing and a second 'Link' DMA from DSP SRAM to the HDaudio FIFO > > (reversed flow for capture). > > So is this approach sufficient for this issue? Or should I explore > other possibilities? A gentle ping... > > Kai-Heng > > >

2 2

[PATCH] ASoC: amd: Return ENODEV if acp63 is not found.
by Tom Rix 06 Jan '23

06 Jan '23

The clang build fails with sound/soc/amd/ps/pci-ps.c:218:2: error: variable 'ret' is used uninitialized whenever switch default is taken [-Werror,-Wsometimes-uninitialized] default: ^~~~~~~ When no device is found -ENODEV should be returned. A switch with a single case is overkill, change to if-else. Fixes: 1d325cdaf7a2 ("ASoC: amd: ps: refactor platform device creation logic") Signed-off-by: Tom Rix <trix(a)redhat.com> --- sound/soc/amd/ps/pci-ps.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/soc/amd/ps/pci-ps.c b/sound/soc/amd/ps/pci-ps.c index 401cfd0036be..cba8800ab4ea 100644 --- a/sound/soc/amd/ps/pci-ps.c +++ b/sound/soc/amd/ps/pci-ps.c @@ -205,8 +205,7 @@ static int create_acp63_platform_devs(struct pci_dev *pci, struct acp63_dev_data memset(&pdevinfo, 0, sizeof(pdevinfo)); } - switch (adata->pdev_mask) { - case ACP63_PDM_DEV_MASK: + if (adata->pdev_mask == ACP63_PDM_DEV_MASK) { adata->pdm_dev_index = 0; acp63_fill_platform_dev_info(&pdevinfo[0], parent, NULL, "acp_ps_pdm_dma", 0, adata->res, 1, NULL, 0); @@ -214,8 +213,8 @@ static int create_acp63_platform_devs(struct pci_dev *pci, struct acp63_dev_data 0, NULL, 0, NULL, 0); acp63_fill_platform_dev_info(&pdevinfo[2], parent, NULL, "acp_ps_mach", 0, NULL, 0, NULL, 0); - break; - default: + } else { + ret = -ENODEV; dev_dbg(&pci->dev, "No PDM devices found\n"); goto de_init; } -- 2.27.0

2 2

[PATCH 14/27] ASoC: PXA: make SND_PXA2XX_SOC_AC97 user-selectable
by Arnd Bergmann 05 Jan '23

05 Jan '23

From: Arnd Bergmann <arnd(a)arndb.de> When building a PXA kernel without legacy board file support, the AC97 code is not built, so none of the AC97 drivers can be used. Add a Kconfig prompt to let users turn it on, and have it enabled by default. Cc: Robert Jarzmik <robert.jarzmik(a)free.fr> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/soc/pxa/Kconfig | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig index a045693d5bc2..2036d368c08d 100644 --- a/sound/soc/pxa/Kconfig +++ b/sound/soc/pxa/Kconfig @@ -16,7 +16,10 @@ config SND_PXA2XX_AC97 tristate config SND_PXA2XX_SOC_AC97 - tristate + tristate "SoC AC97 support for PXA2xx" + depends on SND_PXA2XX_SOC + depends on AC97_BUS=n + default y select AC97_BUS_NEW select SND_PXA2XX_LIB select SND_PXA2XX_LIB_AC97 -- 2.39.0

1 0

[PATCH 1/2] ALSA: hda: cs35l41: Don't return -EINVAL from system suspend/resume
by Takashi Iwai 05 Jan '23

05 Jan '23

The recent commit to support the system suspend for CS35L41 caused a regression on the models with CS35L41_EXT_BOOST_NO_VSPK_SWITC boost type, as the suspend/resume callbacks just return -EINVAL. This is eventually handled as a fatal error and blocks the whole system suspend/resume. For avoiding the problem, this patch corrects the return code from cs35l41_system_suspend() and _resume() to 0, and replace dev_err() with dev_err_once() for stop spamming too much. Fixes: 88672826e2a4 ("ALSA: hda: cs35l41: Support System Suspend") Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/4262e3c4-6169-bbd2-e918-16b06f6994bc@protonmail.c… Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/cs35l41_hda.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/pci/hda/cs35l41_hda.c b/sound/pci/hda/cs35l41_hda.c index 91842c0c8c74..0a5cee730268 100644 --- a/sound/pci/hda/cs35l41_hda.c +++ b/sound/pci/hda/cs35l41_hda.c @@ -598,8 +598,8 @@ static int cs35l41_system_suspend(struct device *dev) dev_dbg(cs35l41->dev, "System Suspend\n"); if (cs35l41->hw_cfg.bst_type == CS35L41_EXT_BOOST_NO_VSPK_SWITCH) { - dev_err(cs35l41->dev, "System Suspend not supported\n"); - return -EINVAL; + dev_err_once(cs35l41->dev, "System Suspend not supported\n"); + return 0; /* don't block the whole system suspend */ } ret = pm_runtime_force_suspend(dev); @@ -624,8 +624,8 @@ static int cs35l41_system_resume(struct device *dev) dev_dbg(cs35l41->dev, "System Resume\n"); if (cs35l41->hw_cfg.bst_type == CS35L41_EXT_BOOST_NO_VSPK_SWITCH) { - dev_err(cs35l41->dev, "System Resume not supported\n"); - return -EINVAL; + dev_err_once(cs35l41->dev, "System Resume not supported\n"); + return 0; /* don't block the whole system resume */ } if (cs35l41->reset_gpio) { -- 2.35.3

2 3

[PATCH] sound: hda: increase timeouts to stop crash on resume with ALC3204 and others
by Ben Carter 05 Jan '23

05 Jan '23

Upon waking after system suspend, ALSA often crashed with: snd_hda_intel 0000:00:1f.3: CORB reset timeout#2, CORBRP = 65535 snd_hda_codec_hdmi hdaudioC1D2: Unable to sync register 0x2f8100. -5 snd_hda_codec_realtek hdaudioC1D0: Unable to sync register 0x2b8000. -5 A temporary fix was established by reloading snd_hda_intel, but increasing the rather strict timeout of 1ms to 100ms has remedied the issue on my device. Although this is a much larger delay, most hardware took less than 1ms anyway and it's preferable to the whole audio system crashing. Signed-off-by: Ben Carter <craterrender(a)gmail.com> --- sound/hda/hdac_controller.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c index 3c7af6558249..1ab573248452 100644 --- a/sound/hda/hdac_controller.c +++ b/sound/hda/hdac_controller.c @@ -16,7 +16,7 @@ static void azx_clear_corbrp(struct hdac_bus *bus) { int timeout; - for (timeout = 1000; timeout > 0; timeout--) { + for (timeout = 100000; timeout > 0; timeout--) { if (snd_hdac_chip_readw(bus, CORBRP) & AZX_CORBRP_RST) break; udelay(1); @@ -26,7 +26,7 @@ static void azx_clear_corbrp(struct hdac_bus *bus) snd_hdac_chip_readw(bus, CORBRP)); snd_hdac_chip_writew(bus, CORBRP, 0); - for (timeout = 1000; timeout > 0; timeout--) { + for (timeout = 100000; timeout > 0; timeout--) { if (snd_hdac_chip_readw(bus, CORBRP) == 0) break; udelay(1); -- 2.39.0

2 1

[PATCH] ALSA: hda/realtek: fix mute/micmute LEDs don't work for a HP platform
by Jeremy Szu 05 Jan '23

05 Jan '23

There is a HP platform uses ALC236 codec which using GPIO2 to control mute LED and GPIO1 to control micmute LED. Thus, add a quirk to make them work. Signed-off-by: Jeremy Szu <jeremy.szu(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index eda4914b8aeb..8362eb4642d8 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -9409,6 +9409,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8ad2, "HP EliteBook 860 16 inch G9 Notebook PC", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8b5d, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), SND_PCI_QUIRK(0x103c, 0x8b5e, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), + SND_PCI_QUIRK(0x103c, 0x8bf0, "HP", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC), SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC282_FIXUP_ASUS_TX300), SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), -- 2.38.1

2 2

A POSIX-compliant shell script for interacting with PCM devices
by Ricardo Biehl Pasquali 05 Jan '23

05 Jan '23

TL;DR: pcm.sh is a ~100 lines script that sets hardware parameters, prepares the device, and forwards data to it, while being POSIX-compliant, readable, and easily customizable. The repository can be found at: <https://github.com/psqli/pcmsh.git> Feel free to suggest changes. Best regards! pasquali

1 0

USB-Audio regression on behringer UMC404HD
by Michael Ralston 04 Jan '23

04 Jan '23

I'm currently experiencing a regression with the audio on my Behringer U-Phoria UMC404HD. Alsa info is at: http://alsa-project.org/db/?f=f453b8cd0248fb5fdfa38e1b770e774102f66135 I get no audio in or out for this device with kernel versions 6.1.1 and 6.1.2. The versions I have tried that work correctly include 5.15.86 LTS, 5.19.12, and 6.0.13–16. When I run this on 6.1.1, it will just hang until I ctrl+c: aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Center.wav I've run strace on that command, and its output is at: https://pastebin.com/WaxJpTMe Nothing out of the ordinary occurs when aplay is run, according to the kernel logs. Please let me know how I can provide additional debugging information if necessary. Thanks Michael

3 23

[PATCH] Revert "ALSA: usb-audio: Drop superfluous interface setup at parsing"
by Takashi Iwai 04 Jan '23

04 Jan '23

This reverts commit ac5e2fb425e1121ceef2b9d1b3ffccc195d55707. The commit caused a regression on Behringer UMC404HD (and likely others). As the change was meant only as a minor optimization, it's better to revert it to address the regression. Reported-and-tested-by: Michael Ralston <michael(a)ralston.id.au> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/CAC2975JXkS1A5Tj9b02G_sy25ZWN-ys+tc9wmkoS=qPgKCog… Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/usb/stream.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/usb/stream.c b/sound/usb/stream.c index f75601ca2d52..f10f4e6d3fb8 100644 --- a/sound/usb/stream.c +++ b/sound/usb/stream.c @@ -1222,6 +1222,12 @@ static int __snd_usb_parse_audio_interface(struct snd_usb_audio *chip, if (err < 0) return err; } + + /* try to set the interface... */ + usb_set_interface(chip->dev, iface_no, 0); + snd_usb_init_pitch(chip, fp); + snd_usb_init_sample_rate(chip, fp, fp->rate_max); + usb_set_interface(chip->dev, iface_no, altno); } return 0; } -- 2.35.3

1 0

[regression, 5.10.y] Bug 216861 - sound disappearance on Acer Swift 3 SF314-59-78UR after update to 5.10.157
by Thorsten Leemhuis 04 Jan '23

04 Jan '23

Hi, this is your Linux kernel regression tracker speaking. I noticed a regression report in bugzilla.kernel.org. As many (most?) kernel developer don't keep an eye on it, I decided to forward it by mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216861 : > Sergey 2022-12-29 10:07:51 UTC > > Created attachment 303497 [details] > pulseaudio.log > > Sudden sound disappearance was reported for some laptops, e.g. > > Acer Swift 3 SF314-59-78UR 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz > > # lspci > 0000:00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20) > Subsystem: Acer Incorporated [ALI] Device 148c > Flags: bus master, fast devsel, latency 32, IRQ 197, IOMMU group 12 > Memory at 601f270000 (64-bit, non-prefetchable) [size=16K] > Memory at 601f000000 (64-bit, non-prefetchable) [size=1M] > Capabilities: [50] Power Management version 3 > Capabilities: [80] Vendor Specific Information: Len=14 <?> > Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Kernel driver in use: sof-audio-pci > > I am attaching the pulseaudio and dmesg logs > > This bug started reproducing after updating the kernel from 5.10.156 to 5.10.157 > > Bisection revealed the commit being reverted: > > c34db0d6b88b1da95e7ab3353e674f4f574cccee is the first bad commit > commit c34db0d6b88b1da95e7ab3353e674f4f574cccee > Author: Richard Fitzgerald <rf(a)opensource.cirrus.com> > Date: Fri Nov 4 13:22:13 2022 +0000 > > ASoC: soc-pcm: Don't zero TDM masks in __soc_pcm_open() > > [ Upstream commit 39bd801d6908900e9ab0cdc2655150f95ddd4f1a ] > > The DAI tx_mask and rx_mask are set by snd_soc_dai_set_tdm_slot() > and used by later code that depends on the TDM settings. So > __soc_pcm_open() should not be obliterating those mask values. > > [...] > Original bug report: https://bugzilla.altlinux.org/44690 See the ticket for more details. BTW, let me use this mail to also add the report to the list of tracked regressions to ensure it's doesn't fall through the cracks: #regzbot introduced: c34db0d6b88b1d https://bugzilla.kernel.org/show_bug.cgi?id=216861 #regzbot title: sound: asoc: sudden sound disappearance #regzbot ignore-activity Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.

6 9