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

[PATCH v2 0/1] ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master after reboot from Windows
by Christian Lachner 03 Jan '22

03 Jan '22

This is version 2 of my patch. It implements suggestions from Takashi Iwai. Thanks for that! Furthermore, I re-analyzed all the relevant coefs and removed those that are not actually needed. === This patch addresses an issue where after rebooting from Windows into Linux there would be no audio output. It turns out that the Realtek Audio driver on Windows changes some coeffs which are not being reset/reinitialized when rebooting the machine. As a result, there is no audio output until these coeffs are being reset to their initial state. This patch takes care of that by setting known-good (initial) values to the coeffs. The coeffs were collected via alsa-info, see: broken: https://pastebin.com/4bRBSseH working: https://pastebin.com/WUTufvZB I also created a script which fixes the audio at runtime. #!/bin/sh hda-verb /dev/snd/hwC2D0 0x20 SET_COEF_INDEX 0x1a hda-verb /dev/snd/hwC2D0 0x20 SET_PROC_COEF 0x01c1 hda-verb /dev/snd/hwC2D0 0x20 SET_COEF_INDEX 0x1b hda-verb /dev/snd/hwC2D0 0x20 SET_PROC_COEF 0x0202 hda-verb /dev/snd/hwC2D0 0x20 SET_COEF_INDEX 0x43 hda-verb /dev/snd/hwC2D0 0x20 SET_PROC_COEF 0x3005 However, obviously, we can and should fix this in the kernel. We initially relied upon alc1220_fixup_clevo_p950() to fix some pins in the connection list. However, it also sets coef 0x7 which does not need to be touched. Furthermore, to prevent mixing device-specific quirks I introduced a new alc1220_fixup_gb_x570() which is heavily based on alc1220_fixup_clevo_p950() but does not set coeff 0x7 and fixes the coeffs that are actually needed instead. This new alc1220_fixup_gb_x570() is believed to also work for other boards, like the Gigabyte X570 Aorus Extreme and the newer Gigabyte Aorus X570S Master. However, as there is no way for me to test these I initially only enable this new behaviour for the mainboard I have which is the Gigabyte X570(non-S) Aorus Master. I tested this patch on the 5.15 branch as well as on master and it is working well for me. Christian Lachner (1): ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master after reboot from Windows sound/pci/hda/patch_realtek.c | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH 0/3] More amlogic sound-name-prefix DT fixes
by Alexander Stein 03 Jan '22

03 Jan '22

Following up [1] here are more fix for missing sound-name-prefix properties in the arch/arm64/boot/dts/amlogic/ subtree. [1] https://www.spinics.net/lists/devicetree/msg466125.html Alexander Stein (3): dt-bindings: display: meson-dw-hdmi: add missing sound-name-prefix property ASoC: dt-bindings: spdif-dit: add missing sound-name-prefix property ASoC: dt-bindings: aiu: spdif-dit: add missing sound-name-prefix property .../devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml | 5 +++++ Documentation/devicetree/bindings/sound/amlogic,aiu.yaml | 5 +++++ Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml | 5 +++++ 3 files changed, 15 insertions(+) -- 2.34.1

3 6

[RESEND] Amlogic DPCM audio card(s) speaker placement issue
by Christian Hewitt 03 Jan '22

03 Jan '22

Hello alsa-dev people, I’d like to describe a problem with speaker placement seen with the Amlogic (meson) AIU and AXG drivers when playing multi-channel media. The problem was traced to a failure to get the channel map via snd_pcm_get_chmap() and further analysis showed this failed because the PCM controls are exposed on a different device than the PCM stream. e.g. on LibreTech LePotato with DPCM routing configured for HDMI output, the hw PCM is on the single frontend device 0 but the PCM controls are on device 2: LePotato:~ # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: LIBRETECHCC [LIBRETECH-CC], device 0: fe.dai-link-0 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 LePotato:~ # amixer controls numid=19,iface=MIXER,name='PCM Playback Volume' numid=18,iface=MIXER,name='ACODEC Left DAC Sel' numid=7,iface=MIXER,name='ACODEC Mute Ramp Switch' numid=2,iface=MIXER,name='ACODEC Playback Channel Mode' numid=3,iface=MIXER,name='ACODEC Playback Switch' numid=4,iface=MIXER,name='ACODEC Playback Volume' numid=5,iface=MIXER,name='ACODEC Ramp Rate' numid=17,iface=MIXER,name='ACODEC Right DAC Sel' numid=8,iface=MIXER,name='ACODEC Unmute Ramp Switch' numid=6,iface=MIXER,name='ACODEC Volume Ramp Switch' numid=1,iface=MIXER,name='AIU ACODEC I2S Lane Select' numid=16,iface=MIXER,name='AIU ACODEC OUT EN Switch' numid=15,iface=MIXER,name='AIU ACODEC SRC' numid=14,iface=MIXER,name='AIU HDMI CTRL SRC' numid=13,iface=MIXER,name='AIU SPDIF SRC SEL' numid=12,iface=PCM,name='ELD',device=2 numid=11,iface=PCM,name='IEC958 Playback Default',device=2 numid=10,iface=PCM,name='IEC958 Playback Mask',device=2 numid=9,iface=PCM,name='Playback Channel Map',device=2 https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/m… or on a Wetek Play 2: WP2:~ # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: WETEKPLAY2 [WETEK-PLAY2], device 0: fe.dai-link-0 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: WETEKPLAY2 [WETEK-PLAY2], device 1: fe.dai-link-1 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 WP2:~ # amixer controls numid=7,iface=MIXER,name='PCM Playback Volume' numid=6,iface=MIXER,name='AIU HDMI CTRL SRC' numid=5,iface=MIXER,name='AIU SPDIF SRC SEL' numid=4,iface=PCM,name='ELD',device=4 numid=3,iface=PCM,name='IEC958 Playback Default',device=4 numid=2,iface=PCM,name='IEC958 Playback Mask',device=4 numid=1,iface=PCM,name='Playback Channel Map',device=4 https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/m… It looks like the PCM controls of the backend hdmi-codec are not routed through the DPCM driver the same way as PCM streams. We discussed that issue with Jerome, the driver author, but it’s not clear which bits we are missing. i.e. if it's something ASoC DPCM should be handling or if some further plumbing in the card driver or userspace is needed? Any hints into the right direction would be highly appreciated! Christian

3 4

slow snd_rawmidi_drain() for VirMidi devcies
by Stefan Sauer 02 Jan '22

02 Jan '22

hi, happy new year every one. During the free days I've tried to link BitwigStudio to the webapp [1]cables.gl over virmidi. Unfortunately Bitwig Studio only supports rawmidi. What I discovered is that there is a strange slowness when sending data to virmidi caused by snd_rawmidi_drain(). I've posted two tiny, self-contained c apps to: [2]https://gist.github.com/ensonic/c7588b87fa6c1fa94a8f753b1e0aa394 See some examples below. 2 observations: * snd_rawmidi_type() is *not* reporting virmidi as VIRTUAL * snd_rawmidi_drain() takes about 60ms! on virtual vs. less that 0.1 ms on usb midi (I checked all my hw midi and the worst was avg=1ms on physical midi image unitor8) When comparing the implementations: [3]https://github.com/alsa-project/alsa-lib/blob/master/ src/rawmidi/rawmidi_virt.c#L173 [4]https://github.com/alsa-project/alsa-lib/blob/master/ src/rawmidi/rawmidi_hw.c#L164 I see that the hw one results in an IOCTL (SNDRV_RAWMIDI_IOCTL_DRAIN) which I can see when strac'ing app and I wonder if this is the root cause? Why is rawmidi_virt.c not used for virmidi? From poking at snd_rawmidi_open_conf() I have not yet figured where this is decided .... If the IOCTl is the right code path, any idea why it is slow? Is the virmidi driver not reporting buffer fill status or something like that? Stefan > amidi -l Dir Device Name IO hw:0,0,0 Scarlett 18i20 USB MIDI 1 IO hw:3,0,0 nanoKEY2 nanoKEY2 _ KEYBOARD IO hw:5,0,0 nanoKONTROL nanoKONTROL _ SLIDE IO hw:10,0 Virtual Raw MIDI (16 subdevices) IO hw:11,0 Virtual Raw MIDI (16 subdevices) # using direct i/o to virmidi - all good > ./rawmidi_oss /dev/midi11 0 Using device '/dev/midi11' without draining write took min= 0.0015 ms, avg= 0.0016 ms, max= 0.0110 ms > ./rawmidi_oss /dev/midi11 1 Using device '/dev/midi11' with draining write took min= 0.0015 ms, avg= 0.0017 ms, max= 0.0101 ms drain took min= 0.0001 ms, avg= 0.0001 ms, max= 0.0008 ms # using snd_rawmidi to virmidi - slow drain operations > ./rawmidi_alsa hw:11,0 0 Using device 'hw:11,0' without draining SND_RAWMIDI_TYPE_HW write took min= 0.0010 ms, avg= 0.0011 ms, max= 0.0056 ms > ./rawmidi_alsa hw:11,0 1 Using device 'hw:11,0' with draining SND_RAWMIDI_TYPE_HW write took min= 0.0016 ms, avg= 0.0040 ms, max= 0.0077 ms drain took min= 55.9951 ms, avg= 60.4330 ms, max= 64.0653 ms # using snd_rawmidi to usb hw - all good > ./rawmidi_alsa hw:3,0 0 Using device 'hw:3,0' without draining SND_RAWMIDI_TYPE_HW write took min= 0.0012 ms, avg= 0.0015 ms, max= 0.0121 ms > ./rawmidi_alsa hw:3,0 1 Using device 'hw:3,0' with draining SND_RAWMIDI_TYPE_HW write took min= 0.0024 ms, avg= 0.0032 ms, max= 0.0110 ms drain took min= 0.0293 ms, avg= 0.0636 ms, max= 0.2277 ms References 1. http://cables.gl/ 2. https://gist.github.com/ensonic/c7588b87fa6c1fa94a8f753b1e0aa394 3. https://github.com/alsa-project/alsa-lib/blob/master/src/rawmidi/rawmidi_vi… 4. https://github.com/alsa-project/alsa-lib/blob/master/src/rawmidi/rawmidi_hw…

1 0

src/topology/parser.c: drop duplicate safe_strtol_base
by GitHub pull_request - opened 01 Jan '22

01 Jan '22

alsa-project/alsa-lib pull request #208 was opened from ffontaine: `safe_strtol_base` is defined twice since https://github.com/alsa-project/alsa-lib/commit/f547b2e35f71e89397e8b29cd0b… and https://github.com/alsa-project/alsa-lib/commit/5fab157a593180525607b7d2626… resulting in the following build failure when alsa-utils is built statically: ``` checking for snd_tplg_new in -latopology... no configure: error: No linkable libatopology was found. ``` because `safe_strtol_base` is defined twice: ``` configure:7776: checking for snd_tplg_new in -latopology configure:7801: /home/buildroot/autobuild/instance-2/output-1/host/bin/arm-linux-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -static -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -static conftest.c -latopology -lasound -lasound -lm -lpthread >&5 /home/buildroot/autobuild/instance-2/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/9.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: /home/buildroot/autobuild/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libasound.a(conf.o): in function `safe_strtol_base': conf.c:(.text+0x1600): multiple definition of `safe_strtol_base'; /home/buildroot/autobuild/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libatopology.a(parser.o):parser.c:(.text+0x130): first defined here ``` Fixes: - http://autobuild.buildroot.org/results/08d028004090b2a8292f03910cb9bf80a73a… Request URL : https://github.com/alsa-project/alsa-lib/pull/208 Patch URL : https://github.com/alsa-project/alsa-lib/pull/208.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

src/topology/parser.c: drop duplicate safe_strtol_base
by GitHub pull_request - opened 01 Jan '22

01 Jan '22

alsa-project/alsa-lib pull request #207 was opened from ffontaine: `safe_strtol_base` is defined twice since https://github.com/alsa-project/alsa-lib/commit/f547b2e35f71e89397e8b29cd0b… and https://github.com/alsa-project/alsa-lib/commit/5fab157a593180525607b7d2626… resulting in the following build failure when alsa-utils is built statically: ``` checking for snd_tplg_new in -latopology... no configure: error: No linkable libatopology was found. ``` because `safe_strtol_base` is defined twice: ``` configure:7776: checking for snd_tplg_new in -latopology configure:7801: /home/buildroot/autobuild/instance-2/output-1/host/bin/arm-linux-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -static -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -static conftest.c -latopology -lasound -lasound -lm -lpthread >&5 /home/buildroot/autobuild/instance-2/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/9.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: /home/buildroot/autobuild/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libasound.a(conf.o): in function `safe_strtol_base': conf.c:(.text+0x1600): multiple definition of `safe_strtol_base'; /home/buildroot/autobuild/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libatopology.a(parser.o):parser.c:(.text+0x130): first defined here ``` Fixes: - http://autobuild.buildroot.org/results/08d028004090b2a8292f03910cb9bf80a73a… Signed-off-by: Fabrice Fontaine <fontaine.fabrice(a)gmail.com> Request URL : https://github.com/alsa-project/alsa-lib/pull/207 Patch URL : https://github.com/alsa-project/alsa-lib/pull/207.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH v4 0/3] Fix Tegra194 HDA regression
by Sameer Pujar 01 Jan '22

01 Jan '22

HDA probe failure is observed on Tegra194 based platforms and this happens due to reset failure. This series fixes the problem by skipping the failing reset and DT bindings are updated accordingly. Changelog ========= v3 -> v4: --------- * Rename SoC data variable in HDA driver patch. * Remove NULL check for compatible match data in HDA driver patch. * Drop "Depends-on" tag from commit message and add "Reviewed-by" tag from Dmitry. * Update binding doc patch as per comment from Rob. v2 -> v3: --------- * Use reset bulk APIs in HDA driver as suggested by Dmitry. v1 -> v2: --------- * Updated HDA driver patch to skip the failing reset instead of skipping resets in general for BPMP devices as per comment from Dmitry. * Used a better strucure name for SoC data as per comment from Thierry. * Dropped 'Fixes' tag in binding doc patch as per comment from Dmitry. Sameer Pujar (3): ALSA: hda/tegra: Fix Tegra194 HDA reset failure dt-bindings: sound: tegra: Add minItems for resets arm64: tegra: Remove non existent Tegra194 reset .../bindings/sound/nvidia,tegra30-hda.yaml | 2 + arch/arm64/boot/dts/nvidia/tegra194.dtsi | 5 +-- sound/pci/hda/hda_tegra.c | 43 +++++++++++++++++----- 3 files changed, 38 insertions(+), 12 deletions(-) -- 2.7.4

2 4