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

realtek ALC1220 : recording samplerate 10x too slow
by cblondin＠mail.com 23 Mar '22

23 Mar '22

Hi, I was redirected here by pulseaudio maintainers for an issue I thought was at that layer : https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1344 After a fresh reboot, arecord / parecord work fine, and the level meters in pavucontrol react normally. If I start audacity, the card gets in a state where the level meters become sluggish, and recording either drops 90% of samples, or records approximately 10x too fast. Playback is always ok, unaffected. I cannot fix that state other than by a reboot. The obvious "closing audacity", restarting the pulseaudio daemon, have no effect. Tried kernels 5.15.24 and a recent 5.17; same problem. I posted some detailed debugging info on that pulseaudio issue tracker, as well as pastebinned alsa-info.sh output here: http://alsa-project.org/db/?f=7ee784003379252acfef25de5fecbdfd559fe342 The problematic hardware is Card 1, Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) HD Audio Controller [1022:1457]. Test command : pasuspender -- arecord -D hw:1,0 -f S16_LE -c 2 -r 44100 arec_pasusp.wav Here's an example recording of me saying 'test' : https://gitlab.freedesktop.org/pulseaudio/pulseaudio/uploads/5a51081fcd55ec… I have no ~/.asoundrc or related files. Anything I can try to narrow down the cause of this ? Thanks! Chris

3 3

[PATCH v5 00/16] Support external boost at CS35l41 ASoC driver
by Lucas Tanure 23 Mar '22

23 Mar '22

Move the support for CS35L41 external boost to its shared library for ASoC use. This move resulted in cs35l41_hda_reg_sequence being removed, and its steps were broken down into regmap writes or functions from the library. And hardware configuration struct was unified for its use in the shared lib. While at it, some minor bugs were found and fixed it. v5 changelog: - Fixed wrong indentation at Documentation patch - Use of consistent prefix v4 changelog: - Separated GPIO 1 and 2 function enums v3 changelog: - Remove patches already accepted - Improved logic in documentation patch - Documentation patch goes before its code - Fixed missing Signed-off-by - Fixed subject for HDA patches v2 changelog: - Instead of removing the log, playback actions will log the last regmap access. - Documentation patch with the correct subject line and fixed bug reported by Rob Herring on the provided example. Previous versions: v1: https://lkml.org/lkml/2022/3/3/759 v2: https://lkml.org/lkml/2022/3/4/743 v3: https://lkml.org/lkml/2022/3/8/975 v4: https://lkml.org/lkml/2022/3/17/267 David Rhodes (1): ASoC: cs35l41: Document CS35l41 External Boost Lucas Tanure (15): ALSA: cs35l41: Unify hardware configuration ALSA: cs35l41: Check hw_config before using it ALSA: cs35l41: Move cs35l41_gpio_config to shared lib ALSA: hda: cs35l41: Fix I2S params comments ALSA: hda: cs35l41: Always configure the DAI ALSA: hda: cs35l41: Add Boost type flag ALSA: hda: cs35l41: Put the device into safe mode for external boost ALSA: hda: cs35l41: Mute the device before shutdown ALSA: cs35l41: Enable Internal Boost in shared lib ALSA: hda: cs35l41: Move boost config to initialization code ALSA: hda: cs35l41: Remove cs35l41_hda_reg_sequence struct ALSA: hda: cs35l41: Reorganize log for playback actions ALSA: hda: cs35l41: Handle all external boost setups the same way ALSA: hda: cs35l41: Move external boost handling to lib for ASoC use ASoC: cs35l41: Support external boost .../bindings/sound/cirrus,cs35l41.yaml | 44 ++- include/sound/cs35l41.h | 59 +++- sound/pci/hda/cs35l41_hda.c | 295 ++++++------------ sound/pci/hda/cs35l41_hda.h | 27 +- sound/soc/codecs/cs35l41-i2c.c | 4 +- sound/soc/codecs/cs35l41-lib.c | 190 ++++++++++- sound/soc/codecs/cs35l41-spi.c | 4 +- sound/soc/codecs/cs35l41.c | 166 +++++----- sound/soc/codecs/cs35l41.h | 5 +- 9 files changed, 443 insertions(+), 351 deletions(-) -- 2.35.1

2 17

[PATCH 0/4] ALSA: pcm: Fix ioctl races
by Takashi Iwai 23 Mar '22

23 Mar '22

Hi, this is a patch set to address the recently reported bug for the racy PCM ioctls. In short, the current ALSA PCM core doesn't take enough care of concurrent ioctl calls, and the concurrent calls may result in a use-after-free. The reported problem was the concurrent hw_free calls, but there can be similar cases with other code paths like hw_params, prepare, etc, too. The patch set introduces the new runtime->buffer_mutex for protecting those. The first patch is the fix for the reported issue (the races with hw_free), while the rest three are more hardening for the other similar executions. [ Note that the patch 3 was slightly modified from the version I sent to distros list, as I noticed possible lockdep (false-positive) warnings. The behavior is almost same, just written differently. ] thanks, Takashi === Takashi Iwai (4): ALSA: pcm: Fix races among concurrent hw_params and hw_free calls ALSA: pcm: Fix races among concurrent read/write and buffer changes ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls ALSA: pcm: Fix races among concurrent prealloc proc writes include/sound/pcm.h | 1 + sound/core/pcm.c | 2 + sound/core/pcm_lib.c | 4 ++ sound/core/pcm_memory.c | 11 +++-- sound/core/pcm_native.c | 93 +++++++++++++++++++++++++---------------- 5 files changed, 71 insertions(+), 40 deletions(-) -- 2.31.1

3 8

[PATCH v3 0/6] ASoC: mediatek: Add support for MT8195 sound card with max98390 and rt5682
by Trevor Wu 23 Mar '22

23 Mar '22

This series of patches adds support for mt8195 board with mt6359, max98390 and rt5682. To prevent from copy-paste components, mt8195 machine drivers and dt-bindings are merged in the patch. Patches are based on broonie tree "for-next" branch. Changes since v2: - split "merge machine driver" into two parts for better understanding Changes since v1: - remove merged patches about reset controller - propose a common machine driver instead of machine driver common code - propose a common dt-bindings for mt8195 sound card Trevor Wu (6): ASoC: mediatek: mt8195: revise mt8195-mt6359-rt1019-rt5682.c ASoC: mediatek: mt8195: merge machine driver ASoC: dt-bindings: mediatek: mt8195: merge mt8195 machine yaml ASoC: mediatek: mt8195: rename card controls ASoC: mediatek: mt8195: add machine support for max98390 and rt5682 ASoC: dt-bindings: mediatek: mt8195: support mt8195-mt6359-max98390-rt5682 .../sound/mt8195-mt6359-rt1011-rt5682.yaml | 51 - ...-rt1019-rt5682.yaml => mt8195-mt6359.yaml} | 9 +- sound/soc/mediatek/Kconfig | 26 +- sound/soc/mediatek/mt8195/Makefile | 3 +- .../mt8195/mt8195-mt6359-rt1011-rt5682.c | 1198 ----------------- ...mt6359-rt1019-rt5682.c => mt8195-mt6359.c} | 865 +++++++----- 6 files changed, 569 insertions(+), 1583 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml rename Documentation/devicetree/bindings/sound/{mt8195-mt6359-rt1019-rt5682.yaml => mt8195-mt6359.yaml} (84%) delete mode 100644 sound/soc/mediatek/mt8195/mt8195-mt6359-rt1011-rt5682.c rename sound/soc/mediatek/mt8195/{mt8195-mt6359-rt1019-rt5682.c => mt8195-mt6359.c} (78%) -- 2.18.0

3 14

[PATCH v3 1/2] Rename tas2764 to tas27xx
by Raphael-Xu 23 Mar '22

23 Mar '22

Signed-off-by: Raphael-Xu <13691752556(a)139.com> --- sound/soc/codecs/{tas2764.c => tas27xx.c} | 0 sound/soc/codecs/{tas2764.h => tas27xx.h} | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename sound/soc/codecs/{tas2764.c => tas27xx.c} (100%) rename sound/soc/codecs/{tas2764.h => tas27xx.h} (100%) diff --git a/sound/soc/codecs/tas2764.c b/sound/soc/codecs/tas27xx.c similarity index 100% rename from sound/soc/codecs/tas2764.c rename to sound/soc/codecs/tas27xx.c diff --git a/sound/soc/codecs/tas2764.h b/sound/soc/codecs/tas27xx.h similarity index 100% rename from sound/soc/codecs/tas2764.h rename to sound/soc/codecs/tas27xx.h -- 2.35.1

3 3

[PATCH] ASoC: amd: Fix duplicate included module.h/io.h
by Haowen Bai 23 Mar '22

23 Mar '22

Clean up the following includecheck warning: sound/soc/amd/vangogh/acp5x-mach.c: linux/module.h is included more than once. sound/soc/amd/vangogh/acp5x-mach.c: linux/io.h is included more than once. No functional change. Signed-off-by: Haowen Bai <baihaowen(a)meizu.com> --- sound/soc/amd/vangogh/acp5x-mach.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/amd/vangogh/acp5x-mach.c b/sound/soc/amd/vangogh/acp5x-mach.c index 14cf325..cc8316b 100644 --- a/sound/soc/amd/vangogh/acp5x-mach.c +++ b/sound/soc/amd/vangogh/acp5x-mach.c @@ -17,10 +17,8 @@ #include <linux/clk.h> #include <linux/gpio.h> #include <linux/gpio/consumer.h> -#include <linux/module.h> #include <linux/i2c.h> #include <linux/input.h> -#include <linux/io.h> #include <linux/acpi.h> #include <linux/dmi.h> -- 2.7.4

1 0

Line-in is abnormally loud for snd-intel-hda
by GitHub issues - opened 22 Mar '22

22 Mar '22

alsa-project/alsa-lib issue #219 was opened from mpeter50: When I'm on Windows, I sometimes use the line-in Jack to connect my phone to it, so I can either listen to it's sounds along with my PCs sounds or use it as a microphone. I've tried to set this functionality up on my Linux installation, but it seems something is not right. The most basic example is with `arecord`: after setting line-in as the default input device with `alsamixer` I've ran `arecord -vv -fdat foo.wav` so I can check what the ALSA drivers actually "hear" without possible interference of any audio servers. While the command was running, I changed the volume of line-in using he appropriate slider of pavucontrol. When playing the recording, it is clear that while line-in is at 100%, the sound is so loud that it is distorted, and the normal volume is around 12-15% of the actual volume. I don't experience this on Windows, so this is probably not a hardware issue. If I plug a headphone directly into my phone and listen to it, the volume is normal, so this is probably not an issue on the signal producer side either. Checking with `alsamixer`, all capture controls are at 0 volume. But, the controls there might not tell the full truth for multiple reasons: - after reducing the Capture control's volume I can still hear the sound coming from line-in - the Capture control's volume is not in sync with what I see in pavucontrol and other places like KDE's volume menu - the controls Master and PCM in the Playback category does not seem to have any effect. As such, none of the controls control the actual output to my headphone - the "default" card has a single slider, it is named Master and this actually controls the master volume, at least for my headphone Screenshot relevant to the 1st and 2nd points: ![image](https://user-images.githubusercontent.com/83356418/159570560-879f2508-d48c-4718-bf7e-34ee80a4c2e6.png) Additional information: - output of the alsa-info script: [alsa-info.txt](https://github.com/alsa-project/alsa-lib/files/8327703/alsa-… - Content of `/proc/asound/card*/codec#*` files: - [/proc/asound/card0/codec#0](https://github.com/alsa-project/alsa-lib/files/8327730/card0_codec0.txt) - [/proc/asound/card1/codec#0](https://github.com/alsa-project/alsa-lib/files/8327735/card1_codec0.txt) - note: card0 is the HDMI section of my graphics card. I never use it for audio, only jack and bluetooth, so it can probably be ignored - output of `lspci -vvnn`: [lspci.txt](https://github.com/alsa-project/alsa-lib/files/8327777/lspci.txt) Issue URL : https://github.com/alsa-project/alsa-lib/issues/219 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH v2] ALSA: hda/realtek: Add alc256-samsung-headphone fixup
by Matt Kramer 22 Mar '22

22 Mar '22

Changes since v1: Formatting (forgot to disable word-wrap, sorry). This fixes the near-silence of the headphone jack on the ALC256-based Samsung Galaxy Book Flex Alpha (NP730QCJ). The magic verbs were found through trial and error, using known ALC298 hacks as inspiration. The fixup is auto-enabled only when the NP730QCJ is detected. It can be manually enabled using model=alc256-samsung-headphone. Signed-off-by: Matt Kramer <mccleetus(a)gmail.com> --- Documentation/sound/hd-audio/models.rst | 4 ++++ sound/pci/hda/patch_realtek.c | 11 +++++++++++ 2 files changed, 15 insertions(+) diff --git a/Documentation/sound/hd-audio/models.rst b/Documentation/sound/hd-audio/models.rst index d25335993e55..9b52f50a6854 100644 --- a/Documentation/sound/hd-audio/models.rst +++ b/Documentation/sound/hd-audio/models.rst @@ -261,6 +261,10 @@ alc-sense-combo huawei-mbx-stereo Enable initialization verbs for Huawei MBX stereo speakers; might be risky, try this at your own risk +alc298-samsung-headphone + Samsung laptops with ALC298 +alc256-samsung-headphone + Samsung laptops with ALC256 ALC66x/67x/892 ============== diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 1d14be4ee31d..f6ee67f41c45 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6958,6 +6958,7 @@ enum { ALC236_FIXUP_HP_MUTE_LED, ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF, ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, + ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, ALC295_FIXUP_ASUS_MIC_NO_PRESENCE, ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS, ALC269VC_FIXUP_ACER_HEADSET_MIC, @@ -8286,6 +8287,14 @@ static const struct hda_fixup alc269_fixups[] = { { } }, }, + [ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET] = { + .type = HDA_FIXUP_VERBS, + .v.verbs = (const struct hda_verb[]) { + { 0x20, AC_VERB_SET_COEF_INDEX, 0x08}, + { 0x20, AC_VERB_SET_PROC_COEF, 0x2fcf}, + { } + }, + }, [ALC295_FIXUP_ASUS_MIC_NO_PRESENCE] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { @@ -9099,6 +9108,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x144d, 0xc740, "Samsung Ativ book 8 (NP870Z5G)", ALC269_FIXUP_ATIV_BOOK_8), SND_PCI_QUIRK(0x144d, 0xc812, "Samsung Notebook Pen S (NT950SBE-X58)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET), SND_PCI_QUIRK(0x144d, 0xc830, "Samsung Galaxy Book Ion (NT950XCJ-X716A)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET), + SND_PCI_QUIRK(0x144d, 0xc832, "Samsung Galaxy Book Flex Alpha (NP730QCJ)", ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET), SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", ALC283_FIXUP_HEADSET_MIC), SND_PCI_QUIRK(0x1462, 0xb120, "MSI Cubi MS-B120", ALC283_FIXUP_HEADSET_MIC), SND_PCI_QUIRK(0x1462, 0xb171, "Cubi N 8GL (MS-B171)", ALC283_FIXUP_HEADSET_MIC), @@ -9445,6 +9455,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {.id = ALC298_FIXUP_HUAWEI_MBX_STEREO, .name = "huawei-mbx-stereo"}, {.id = ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE, .name = "alc256-medion-headset"}, {.id = ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, .name = "alc298-samsung-headphone"}, + {.id = ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, .name = "alc256-samsung-headphone"}, {.id = ALC255_FIXUP_XIAOMI_HEADSET_MIC, .name = "alc255-xiaomi-headset"}, {.id = ALC274_FIXUP_HP_MIC, .name = "alc274-hp-mic-detect"}, {.id = ALC245_FIXUP_HP_X360_AMP, .name = "alc245-hp-x360-amp"}, -- 2.35.1

2 4

[PATCH BUGFIX] ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec
by Giacomo Guiduzzi 22 Mar '22

22 Mar '22

Tests 72 and 78 for ALSA in kselftest fail due to reading inconsistent values from some devices on a VirtualBox Virtual Machine using the snd_intel8x0 driver for the AC'97 Audio Controller device. Taking for example test number 72, this is what the test reports: "Surround Playback Volume.0 expected 1 but read 0, is_volatile 0" "Surround Playback Volume.1 expected 0 but read 1, is_volatile 0" These errors repeat for each value from 0 to 31. Taking a look at these error messages it is possible to notice that the written values are read back swapped. When the write is performed, these values are initially stored in an array used to sanity-check them and write them in the pcmreg array. To write them, the two one-byte values are packed together in a two-byte variable through bitwise operations: the first value is shifted left by one byte and the second value is stored in the right byte through a bitwise OR. When reading the values back, right shifts are performed to retrieve the previously stored bytes. These shifts are executed in the wrong order, thus reporting the values swapped as shown above. This patch fixes this mistake by reversing the read operations' order. Signed-off-by: Giacomo Guiduzzi <guiduzzi.giacomo(a)gmail.com> Signed-off-by: Paolo Valente <paolo.valente(a)linaro.org> --- sound/pci/ac97/ac97_codec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/ac97/ac97_codec.c b/sound/pci/ac97/ac97_codec.c index 01f296d524ce..cb60a07d39a8 100644 --- a/sound/pci/ac97/ac97_codec.c +++ b/sound/pci/ac97/ac97_codec.c @@ -938,8 +938,8 @@ static int snd_ac97_ad18xx_pcm_get_volume(struct snd_kcontrol *kcontrol, struct int codec = kcontrol->private_value & 3; mutex_lock(&ac97->page_mutex); - ucontrol->value.integer.value[0] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 0) & 31); - ucontrol->value.integer.value[1] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 8) & 31); + ucontrol->value.integer.value[0] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 8) & 31); + ucontrol->value.integer.value[1] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 0) & 31); mutex_unlock(&ac97->page_mutex); return 0; } -- 2.25.1

2 1

Re: Apogee ONEv2 keeps resetting
by Alan Stern 22 Mar '22

22 Mar '22

On Sun, Mar 20, 2022 at 02:15:40AM +0100, Petr Janecek wrote: > Hi, > I'm trying to use Apogee ONEv2. From usb dumps under > macos or windows it seems like a usb Class Audio 2.0 > device, but in linux, it keeps resetting every two seconds > or so. It keeps resetting even when the snd-usb-audio > driver is disabled, so the problem is probably at a lower > level. Can you post the log output on a system where snd-usb-audio is disabled? > The messages below are from v5.16.16, but it behaves > the same no matter what I plug it into. > > [ 253.708616] usb 3-8: new high-speed USB device number 6 using xhci_hcd > [ 253.899363] usb 3-8: New USB device found, idVendor=0c60, idProduct=0017, > bcdDevice= 1.05 > [ 253.899370] usb 3-8: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 253.899373] usb 3-8: Product: ONEv2 > [ 253.899375] usb 3-8: Manufacturer: Apogee > [ 253.899377] usb 3-8: SerialNumber: 0C12FF2020204652334D513A7A2A9B > [ 253.960901] mc: Linux media interface: v0.10 Any idea where that line came from? You should try capturing a usbmon trace showing what happens when the device is plugged in and then resets. Preferably on a system where snd-usb-audio is disabled. One other thing you might try: Disable runtime PM for USB ("echo -1 >/sys/module/usbcore/parameters/autosuspend" before plugging in the device). Alan Stern

1 0