dmix / dsnoop not enabled by default on Raptor Lake HDA

[jerstlouis]

Please re-direct me if this is not the proper place to submit such bug report. Apologies if that's the case.

From support in libera.chat #alsa , I was told that this is similar to a bug that continuously keeps coming back for Intel HDA drivers (e.g., https://forums.gentoo.org/viewtopic-t-913432-start-0.html). I'm not exactly clear how the Linux kernel / audio device drivers / ALSA / SOF projects all relate to each other.

Describe the bug
On a laptop with Intel Raptor Lake HDA, audio mixing does not work by default on ALSA with a simplistic ALSA config or no config at all.

The work around is to create a /etc/asound.conf file with type dmix in pcm.output and type dsnoop in pcm.input.

The loaded driver is snd_sof_pci_intel_tgl on Linux kernel 6.10.0 (or 6.10.6).

The sof_dev_desc for my device is this: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/soc/sof/intel/pci-tgl.c#n219

Multimedia audio controller [0401]: Intel Corporation Raptor Lake High Definition Audio Controller [8086:7a50] (rev 11)

#define PCI_DEVICE_ID_INTEL_HDA_RPL_S 0x7a50

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/pci_ids.h#n3080

To Reproduce
Try playing 2 sounds at the same time with aplay without an ALSA config with a Raptor Lake (14th gen Intel) HDA system such as this Gigabyte AORUS 17X gaming laptop, with Linux 6.10.0 or 6.10.6.

Alternatively this simple asound.conf used to correct the fact that my default sound card is the NVidia HDMI instead of the onboard audio (also a bug in itself?) results in the same problem:

defaults.pcm.card 1
defaults.ctl.card 1

Reproduction Rate
Always.

Expected behavior
ALSA audio mixing should just work by default without a config, and Linux users should not have to choose between intense suffering to just get video conferencing working, or installing pulseaudio to handle mixing.

This is the asound.conf which solves the problems and would hopefully be the default behavior.

Impact
3 months of intense frustration with seemingly random audio-conferencing issues in browsers, which are incredibly difficult to troubleshoot for a regular end-user.

Environment
Running kernel 6.10.0-artix1-2 or 6.10.6-artix1-1

[lgirdwood]

@jerstlouis sorry to hear about the pain in resolving this, normally the soundserver will mix multiple aplays for you by default without the need to configure plugins for mixing (although the soundserver does need to register it self with ALSA with a config file).

I also dont think there is anything new with the Raptor lake HDA vs previous generations to support ALSA plugins. Are you able to share the kernel log of the audio drivers ? Raptor lake also been out a while (I'm using it with Ubuntu now - not seen this issue).

One other thing, have you also tried to reinstall alsa/soundserver, sometimes a missing/renamed/edited config file can cause problems similar to this.

[jerstlouis]

@lgirdwood

normally the soundserver will mix multiple aplays for you by default

Which soundserver? I am explicitly not using pulseaudio (nor pipewire, nor jack), wanting to use the built-in ALSA mixing (which from what I understand should either use hardware mixing when the hardware supports, or falls back to the dmix / dsnoop when it does not). That's what the issue is, that these are not set up by default when not using an ALSA config file.
ALSA should work just fine without a sound server.

have you also tried to reinstall alsa/soundserver

Not sure what you mean by this? On Artix (Arch-based) I imagine there is only those 2 packages alsa-lib and alsa-utils. I have tried a full system upgrade so those should have been reinstalled.

sometimes a missing/renamed/edited config file can cause problems similar to this.

The problem is things not working when I do not have config file set up.
With a config explicitly enabling dsnoop, dmix and plug, everything is working fine.
From the unofficial user support I received in #alsa, I was told this should be the default behavior and it's a driver bug if that is not the case.

Are you able to share the kernel log of the audio drivers

Here is what seems to be relevant from dmesg:

[ 5.542915] snd_hda_intel 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
[ 5.542988] snd_hda_intel 0000:01:00.1: enabling device (0000 -> 0002)
[ 5.543046] snd_hda_intel 0000:01:00.1: Disabling MSI
[ 5.543049] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client

[ 5.687322] sof-audio-pci-intel-tgl 0000:00:1f.3: enabling device (0000 -> 0002)
[ 5.687490] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
[ 5.687539] sof-audio-pci-intel-tgl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 5.694820] sof-audio-pci-intel-tgl 0000:00:1f.3: use msi interrupt mode

[ 5.798607] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 5
[ 5.798613] sof-audio-pci-intel-tgl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
[ 5.798618] sof-audio-pci-intel-tgl 0000:00:1f.3: DMICs detected in NHLT tables: 2
[ 5.801768] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware paths/files for ipc type 0:
[ 5.801772] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware file: intel/sof/sof-rpl-s.ri
[ 5.801774] sof-audio-pci-intel-tgl 0000:00:1f.3: Topology file: intel/sof-tplg/sof-hda-generic-2ch.tplg
[ 5.802410] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864
[ 5.802414] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
[ 5.802420] sof-audio-pci-intel-tgl 0000:00:1f.3: unknown sof_ext_man header type 3 size 0x30

[ 5.888596] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864
[ 5.888608] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
[ 5.908003] sof-audio-pci-intel-tgl 0000:00:1f.3: Topology: ABI 3:22:1 Kernel ABI 3:23:0
[ 5.908116] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not yet available, widget card binding deferred
[ 5.935480] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC256: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[ 5.935487] snd_hda_codec_realtek ehdaudio0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 5.935490] snd_hda_codec_realtek ehdaudio0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[ 5.935492] snd_hda_codec_realtek ehdaudio0D0: mono: mono_out=0x0
[ 5.935493] snd_hda_codec_realtek ehdaudio0D0: inputs:
[ 5.935495] snd_hda_codec_realtek ehdaudio0D0: Mic=0x19
[ 5.980844] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3
[ 6.002935] input: sof-hda-dsp Mic as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card1/input36
[ 6.003145] input: sof-hda-dsp Headphone as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card1/input37
[ 6.003338] input: sof-hda-dsp HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card1/input38
[ 6.003503] input: sof-hda-dsp HDMI/DP,pcm=4 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card1/input39
[ 6.003665] input: sof-hda-dsp HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card1/input40

[kv2019i]

@jerstlouis This is really distribution choice what happens by default. Most distros enable Pipewire or Pulsaudio by default, and dmix/dsnoop is not really that common anymore. There are still setups where native ALSA without any userspace mixing is prefered (e.g. people who want to run JACK and similar apps) and having dmix/snoop by default would not be desirable.

[jerstlouis]

Thanks @kv2019i . I think it's really a matter of clarifying whether there is an expectation that dsnoop/dmix are on by default without an ALSA config in cases where the hardware does not support hardware mixing.

Because without either of those things, audio works terribly in user applications.

People (and distros) can still set up an ALSA config to explicitly disable dmix/dsnoop if they do set up pulseaudio, pipewire or JACK of course. But it seems like the default behavior should be for things to work.

[plbossart]

probably need to ask @perexg for advice.

[perexg]

@jerstlouis : Unfortunately, we do not add legacy configuration for new ASoC drivers to alsa-lib, because users have also other requirements (see bellow). So your special configuration is really an option for users who don't want to bother with pulseaudio/pipewire audio servers on desktop machines.

Requested features:

• plug and play hardware support (like USB or bluetooth) and audio stream rerouting
• audio mixing
• profile support
• multiple PCM device support (per selected profile)

Your config can be reduced as:

# sof-hda-dsp - see /proc/asound/cards (driver identifier in [])
cards.sof-hda-dsp.pcm.dmix {
  period_size 512
  periods 8
}

cards.sof-hda-dsp.pcm.dsnoop { 
  period_size 512
  periods 8
}

# sofhdadsp - see /proc/asound/cards (card identifier / ASCII alias after 'card X:')
pcm.!default {
  type asym
  playback.pcm {
     type plug
     slave.pcm "dmix:CARD=sofhdadsp,CHANNELS=2,RATE=48000"
  }
  capture.pcm {
    type plug
    slave.pcm "dsnoop:CARD=sofhdadsp,CHANNELS=2,RATE=48000"
  }
}

[jerstlouis]

Thanks @perexg . So if there's no guarantee of mixing being available from ALSA itself without a config, I think what would help is much clearer / easier to find documentation on the matter from https://www.alsa-project.org/ on how to set up such a config and why that is needed.