[BUG] TGL Dell XPS 13 9310: Microphone/input does not work

paulmenzel commented 3 years ago

With the Intel Tiger Lake laptop Dell XPS 13 9310 and Debian Sid/unstable with Linux 5.9.6, SOF stable-v1.6 and PulseAudio 13.99.3-1, the user reports, that the internal microphone does not work. First the internal device was only detected after plugging in an external headset, but after selecting SND_SOC_SOF_TIGERLAKE_SUPPORT and installing the SOF stable-v1.6 a multichannel device appears.

gnome-dialog-multichannel-input

But the user says, nothing is detected/recorded over this microphone. PulseAudio is also version 13.99.3, which I understand has all necessary changes. How can I check that?

Maybe you see something in the output of /usr/sbin/alsa-info [Edit: This was run with a test user not in the group audio. Therefore, aplay/arecord don’t show anything, and there are no Linux messages, because it wasn’t run as root required for access to dmesg.]. Also, an excerpt from the Linux messages:

[   10.132876] sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[   10.132878] sof-audio-pci 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
[   10.132888] sof-audio-pci 0000:00:1f.3: enabling device (0000 -> 0002)
[   10.133059] sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
[   11.347094] sof-audio-pci 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   11.353897] sof-audio-pci 0000:00:1f.3: use msi interrupt mode
[   11.375128] sof-audio-pci 0000:00:1f.3: hda codecs found, mask 5
[   11.375130] sof-audio-pci 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
[   11.375132] sof-audio-pci 0000:00:1f.3: DMICs detected in NHLT tables: 2
[   11.377203] sof-audio-pci 0000:00:1f.3: firmware: direct-loading firmware intel/sof/sof-tgl.ri
[   11.481279] sof-audio-pci 0000:00:1f.3: Firmware info: version 1:6:0-18fab
[   11.481281] sof-audio-pci 0000:00:1f.3: Firmware: ABI 3:17:0 Kernel ABI 3:16:0
[   11.481281] sof-audio-pci 0000:00:1f.3: warn: FW ABI is more recent than kernel
[   11.481959] sof-audio-pci 0000:00:1f.3: warning: unknown ext header type 3 size 0x1c
[   11.481975] sof-audio-pci 0000:00:1f.3: warning: unknown ext header type 4 size 0x10
[   11.534359] sof-audio-pci 0000:00:1f.3: firmware: direct-loading firmware intel/sof-tplg/sof-hda-generic-2ch.tplg
[   11.534364] sof-audio-pci 0000:00:1f.3: Topology: ABI 3:17:0 Kernel ABI 3:16:0
[   11.534364] sof-audio-pci 0000:00:1f.3: warn: topology ABI is more recent than kernel
[   11.534367] sof-audio-pci 0000:00:1f.3: warning: widget type 7 name iDisp3 Tx not handled
[   11.535687] sof-audio-pci 0000:00:1f.3: warning: widget type 0 name codec0_in not handled
[   11.535687] sof-audio-pci 0000:00:1f.3: warning: widget type 7 name iDisp2 Tx not handled
[   11.537332] sof-audio-pci 0000:00:1f.3: warning: widget type 0 name codec1_in not handled
[   11.537333] sof-audio-pci 0000:00:1f.3: warning: widget type 7 name iDisp1 Tx not handled
[   11.538577] sof-audio-pci 0000:00:1f.3: warning: widget type 1 name codec0_out not handled
[   11.538578] sof-audio-pci 0000:00:1f.3: warning: widget type 7 name Analog CPU Playback not handled
[   11.540163] sof-audio-pci 0000:00:1f.3: warning: widget type 1 name codec1_out not handled
[   11.540164] sof-audio-pci 0000:00:1f.3: warning: widget type 7 name Digital CPU Playback not handled
[   11.540165] sof-audio-pci 0000:00:1f.3: warning: widget type 0 name codec2_in not handled
[   11.540166] sof-audio-pci 0000:00:1f.3: warning: widget type 7 name Alt Analog CPU Playback not handled
[   11.540166] sof-audio-pci 0000:00:1f.3: warning: widget type 1 name codec2_out not handled
[   11.540167] sof-audio-pci 0000:00:1f.3: warning: widget type 0 name Analog CPU Capture not handled
[   11.541412] sof-audio-pci 0000:00:1f.3: warning: widget type 1 name iDisp1_out not handled
[   11.541412] sof-audio-pci 0000:00:1f.3: warning: widget type 0 name Digital CPU Capture not handled
[   11.542717] sof-audio-pci 0000:00:1f.3: warning: widget type 1 name iDisp2_out not handled
[   11.542717] sof-audio-pci 0000:00:1f.3: warning: widget type 0 name Alt Analog CPU Capture not handled
[   11.544011] sof-audio-pci 0000:00:1f.3: warning: widget type 1 name iDisp3_out not handled
[   11.556552] sof-audio-pci 0000:00:1f.3: ASoC: Parent card not yet available, widget card binding deferred

plbossart commented 3 years ago

That platform looks like a standard HDAudio + 2 mics + Intel HDMI. That should work, we have devices like this left and right.

is the alsa-ucm-conf package up-to-date? It should contain the UCM parts needed to show the dmic.

Also please refer to this documentation to help check dmic issues:

https://thesofproject.github.io/latest/getting_started/index.html#debugging-audio-issues-on-intel-platforms

paulmenzel commented 3 years ago

That platform looks like a standard HDAudio + 2 mics + Intel HDMI. That should work, we have devices like this left and right.

Where do you see that? There is no HDMI connector on the Dell XPS 13 9310 to my knowledge – only USB 3 Type C.

is the alsa-ucm-conf package up-to-date? It should contain the UCM parts needed to show the dmic.

Debian packages alsa-ucm-conf 1.2.3-1.

Also please refer to this documentation to help check dmic issues:

https://thesofproject.github.io/latest/getting_started/index.html#debugging-audio-issues-on-intel-platforms

I can try that on Monday, if the user allows me remote access. Please note, that my issue contains a reference to the output of /usr/sbin/alsa-info. The parts below look strange:

!!Aplay/Arecord output
!!--------------------

APLAY

aplay: device_list:274: no soundcards found...

ARECORD

arecord: device_list:274: no soundcards found...

!!Amixer output
!!-------------

!!-------Mixer controls for card sofhdadsp

Invalid card number.
Usage: amixer <options> [command]

Available options:
  -h,--help       this help

plbossart commented 3 years ago

That platform looks like a standard HDAudio + 2 mics + Intel HDMI. That should work, we have devices like this left and right.

Where do you see that? There is no HDMI connector on the Dell XPS 13 9310 to my knowledge – only USB 3 Type C.

[ 11.375128] sof-audio-pci 0000:00:1f.3: hda codecs found, mask 5

Mask = 0x4 means there is a 'Display Audio' connection handled by Intel. This is helpful to detect if there is an Nvidia/AMD external graphics card handling Display Audio separately. The actual format/connector is irrelevant, what matters is whether SOF handles this audio data or not.

Mask=0x5 means there is both a local HDAudio codec and a 'Display Audio' connection.

is the alsa-ucm-conf package up-to-date? It should contain the UCM parts needed to show the dmic.

Debian packages alsa-ucm-conf 1.2.3-1.

might be worth updating to 1.2.4, but not sure why that would be a problem.

Also please refer to this documentation to help check dmic issues: https://thesofproject.github.io/latest/getting_started/index.html#debugging-audio-issues-on-intel-platforms

I can try that on Monday, if the user allows me remote access. Please note, that my issue contains a reference to the output of /usr/sbin/alsa-info. The parts below look strange:
!!Aplay/Arecord output
!!--------------------

APLAY

aplay: device_list:274: no soundcards found...

ARECORD

arecord: device_list:274: no soundcards found...

!!Amixer output
!!-------------

!!-------Mixer controls for card sofhdadsp

Invalid card number.
Usage: amixer <options> [command]

Available options:
  -h,--help       this help

Yes that's not good. This can happen if somehow the card creation fails despite the PCI probe happening without issues. The card creation failure is squelched by the device core.

maybe adding the following options in /etc/modprobe.d/sof-dyndbg.conf would help use figure out what happens

options snd_sof_intel_byt dyndbg=+p
options snd_sof_intel_bdw dyndbg=+p
options snd_sof_intel_ipc dyndbg=+p
options snd_sof_intel_hda_common dyndbg=+p
options snd_sof_intel_hda dyndbg=+p
options snd_sof dyndbg=+p
options snd_sof_pci dyndbg=+p
options snd_sof_acpi dyndbg=+p
options snd_sof_of dyndbg=+p
options snd_sof_nocodec dyndbg=+p
options soundwire_bus dyndbg=+p
options soundwire_generic_allocation dyndbg=+p
options soundwire_cadence dyndbg=+p
options soundwire_intel_init dyndbg=+p
options soundwire_intel dyndbg=+p
options snd_soc_skl_hda_dsp dyndbg=+p
options snd_intel_dspcfg dyndbg=+p

kv2019i commented 3 years ago

@paulmenzel I have a 9310 and can confirm the digital microphone works with SOF without issues. Can you capture also the kernel config that is used?

It seems this is an issue with kernel probe. All components of the SOF PCI card do not get initialized and we are stuck in [ 11.556552] sof-audio-pci 0000:00:1f.3: ASoC: Parent card not yet available, widget card binding deferred

... this could:

some problem with HDMI/DP codec driver (the kernel config might reveal something), I don't see any traces in the log
- could be fixed by https://lore.kernel.org/r/20200921100841.2882662-1-kai.vehmanen@linux.intel.com
bug in backwards compatibility (bug happens with older kernel and newer topology)

In any case, looks like a kernel bug, so moving to kernel and assigning to myself.

paulmenzel commented 3 years ago

@paulmenzel I have a 9310 and can confirm the digital microphone works with SOF without issues.

Thank you for following up on the issue. What distribution and Linux kernel version do you use?

Can you capture also the kernel config that is used?

It’s the Debian Sid/unstable Linux kernel 5.9.6 configuration.

It seems this is an issue with kernel probe. All components of the SOF PCI card do not get initialized and we are stuck in

[ 11.556552] sof-audio-pci 0000:00:1f.3: ASoC: Parent card not yet available, widget card binding deferred

... this could:

* some problem with HDMI/DP codec driver (the kernel config might reveal something), I don't see any traces in the log
  - could be fixed by https://lore.kernel.org/r/20200921100841.2882662-1-kai.vehmanen@linux.intel.com

That is commit 163cd1059a (ASoC: hdac: make SOF HDA codec driver probe deterministic), only in 5.10-rc1 and forward, and not tagged for the stable series.

* bug in backwards compatibility (bug happens with older kernel and newer topology)

What sof-bin release should I try?

kv2019i commented 3 years ago

@paulmenzel I've tested multiple upstream 5.9 kernel versions on Ubuntu, with 5.6 Ubuntu kernel and currently running 5.10-rc1. I've used both SOF FW v1.5 and v1.6, so that should not be the problem.

The kernel config seems ok, so I think https://github.com/torvalds/linux/commit/163cd1059a85d225b811ddb4192fabd1553f77f1 is prime suspect. We haven't received any reports that users would hit this on normal system boot-up flows. If this is indeed the case, we indeed need to backport this to stable.

As an alternative to backporting the patch, following test can be made with existing 5.9.6 kernel: sudo modprobe -r snd_sof_pci sudo modprobe -r snd_hda_codec_hdmi sudo modprobe -r snd_hda_codec_hdmi sudo modprobe -r snd_soc_skl_hda_dsp sudo modprobe snd_sof_pci

This should avoid the problem the patch fixes. If the above still fails, I would like to see kernel logs with dynamic debug enabled (https://github.com/thesofproject/linux/issues/2577#issuecomment-726917545).

paulmenzel commented 3 years ago

@paulmenzel I've tested multiple upstream 5.9 kernel versions on Ubuntu, with 5.6 Ubuntu kernel and currently running 5.10-rc1. I've used both SOF FW v1.5 and v1.6, so that should not be the problem.

Strange. Thank you for checking.

The kernel config seems ok, so I think torvalds@163cd10 is prime suspect. We haven't received any reports that users would hit this on normal system boot-up flows. If this is indeed the case, we indeed need to backport this to stable.

As an alternative to backporting the patch, following test can be made with existing 5.9.6 kernel:
sudo modprobe -r snd_sof_pci
sudo modprobe -r snd_hda_codec_hdmi
sudo modprobe -r snd_hda_codec_hdmi

The line is duplicated. Should it be a different module?

sudo modprobe -r snd_soc_skl_hda_dsp
sudo modprobe snd_sof_pci

The error/warning still appears:

-- 
[99150.653237] sof-audio-pci 0000:00:1f.3: use msi interrupt mode 
[99150.672845] sof-audio-pci 0000:00:1f.3: hda codecs found, mask 5 
[99150.672850] sof-audio-pci 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now 
[99150.672857] sof-audio-pci 0000:00:1f.3: DMICs detected in NHLT tables: 2 
-- 
[99150.807325] sof-audio-pci 0000:00:1f.3: ASoC: Parent card not yet available, widget card binding deferred 
[99150.841635] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC289: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker 
[99150.841635] snd_hda_codec_realtek ehdaudio0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) 
[99150.841636] snd_hda_codec_realtek ehdaudio0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0) 
[99150.841636] snd_hda_codec_realtek ehdaudio0D0:    mono: mono_out=0x0 
[99150.841637] snd_hda_codec_realtek ehdaudio0D0:    inputs: 
[99150.841637] snd_hda_codec_realtek ehdaudio0D0:      Headset Mic=0x19 
[99150.841638] snd_hda_codec_realtek ehdaudio0D0:      Headphone Mic=0x1b 
[99150.903045] snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten 
[99150.903049] snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten 
[99150.903160] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi3 overwritten 
-- 
[99150.903192] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Alt Analog Codec Capture overwritten 
[99150.903199] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3 

[99150.903200] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 4 

[99150.903201] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 5 

[99150.903201] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 6 

[99150.903202] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 7 

[99150.903203] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 8 

[99150.923997] input: sof-hda-dsp Headphone Mic as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input28 
[99150.924023] input: sof-hda-dsp HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input29 
[99150.924053] input: sof-hda-dsp HDMI/DP,pcm=4 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input30 
[99150.924076] input: sof-hda-dsp HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input31

This should avoid the problem the patch fixes. If the above still fails, I would like to see kernel logs with dynamic debug enabled (#2577 (comment)).

I’ll collect that.

kv2019i commented 3 years ago

@paulmenzel wrote:

sudo modprobe -r snd_sof_pci sudo modprobe -r snd_hda_codec_hdmi sudo modprobe -r snd_hda_codec_hdmi

The line is duplicated. Should it be a different module?

D'oh, copy'n'paste error, should be:

sudo modprobe -r snd_soc_hdac_hdmi sudo modprobe -r snd_hda_codec_hdmi

This should avoid the problem the patch fixes. If the above still fails, I would like to see kernel logs with dynamic debug enabled (#2577 (comment)). I’ll collect that.

Might be a bit late ask, but if you read this in time, these would be additionally good:

options snd_hda_core dyndbg=+p options snd_hda_codec dyndbg=+p options snd_hda_ext_core dyndbg=+p options snd_hda_codec_hdmi dyndbg=+p options snd_soc_hdac_hda dyndbg=+p options snd_soc_hdac_hdmi dyndbg=+p

paulmenzel commented 3 years ago

Linux’ log ring buffer was already full, but thankfully the systemd journal stores them too: output of journalctl -k.

Note, the updated Debian Linux kernel 5.9.9 is used from now on.

kv2019i commented 3 years ago

@paulmenzel I think it goes further at least. I think probe now succeeded. I can see PCMs being opened and DSP communication looks ok. Can you confirm output of alsa-info and/or check "aplay -l" now shows the PCM? Was this log with my custom "modprobe sequence" or vanilla Debian boot? I'm asking because at least in this log, bug related to https://github.com/torvalds/linux/commit/163cd1059a85d225b811ddb4192fabd1553f77f1 is not hit.

paulmenzel commented 3 years ago

@paulmenzel I think it goes further at least. I think probe now succeeded. I can see PCMs being opened and DSP communication looks ok.

Great news. Thank you for checking.

Can you confirm output of alsa-info and/or check "aplay -l" now shows the PCM?

Unfortunately, it does not.

$ aplay -l
aplay: device_list:274: no soundcards found...

Was this log with my custom "modprobe sequence" or vanilla Debian boot?

That look was from a vanilla boot with enabled debug options.

I'm asking because at least in this log, bug related to torvalds@163cd10 is not hit.

Good to know. Too bad, as it is something else.

paulmenzel commented 3 years ago

[Sorry, my test user wasn’t in the group audio.]

@paulmenzel I think it goes further at least. I think probe now succeeded. I can see PCMs being opened and DSP communication looks ok.

Great news. Thank you for checking.

Can you confirm output of alsa-info and/or check "aplay -l" now shows the PCM?

Unfortunately, it does not.
$ aplay -l
aplay: device_list:274: no soundcards found...

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 1: HDA Digital (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Was this log with my custom "modprobe sequence" or vanilla Debian boot?

That look was from a vanilla boot with enabled debug options.

I'm asking because at least in this log, bug related to torvalds@163cd10 is not hit.

Good to know. Too bad, as it is something else.

To recap the original problem, the user reported that the Multichannel Input device, although displayed, did not record anything.

kv2019i commented 3 years ago

@paulmenzel Ok, really good that kernel is now ok. As this was with a vanilla Debian boot, I actually wonder what has changed and what triggered the failure to create the sound devices in https://github.com/thesofproject/linux/issues/2577#issuecomment-726894837 . Kernel was changed to 5.9.9, so that's of course one possibility.

For the "Multichannel Input" problem, that sounds a more classical problem of mismatching/too-old ALSA UCM. Some error has occurred when Pulseaudio has loaded the ALSA UCM file, and it has fallen back to legacy HDA mode in Pulseaudio (PA uses hardwired assumptions in its codebase about how HDA devices work, instead of reading this information from a UCM file --> all extra features get dropped when this happens).

By looking at used versions alone, Alsa-lib 1.2.3 and Pulseaudio 13.99.3-1 seem good, so something unexpected is happening here.

To get further, pulseaudio logs would be needed.

paulmenzel commented 3 years ago

@paulmenzel Ok, really good that kernel is now ok. As this was with a vanilla Debian boot, I actually wonder what has changed and what triggered the failure to create the sound devices in #2577 (comment) . Kernel was changed to 5.9.9, so that's of course one possibility.

I am going to look through all the logs this week to find out how often it occurred.

By looking at used versions alone, Alsa-lib 1.2.3 and Pulseaudio 13.99.3-1 seem good, so something unexpected is happening here.

To get further, pulseaudio logs would be needed.

Output of journalctl --user -u pulseaudio.service -b) with PA daemon log level debug

(Should I create a separate issue for that?)

kv2019i commented 3 years ago

@paulmenzel Ok, something wrong with the alsa-ucm package?

Nov 30 11:33:11 ortiz pulseaudio[24457]: Unable to find the top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'. Nov 30 11:33:11 ortiz pulseaudio[24457]: error: failed to import hw:0 use case configuration -2 Nov 30 11:33:11 ortiz pulseaudio[24457]: Unable to find the top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'. Nov 30 11:33:11 ortiz pulseaudio[24457]: error: failed to import sof-hda-dsp use case configuration -2 Nov 30 11:33:11 ortiz pulseaudio[24457]: UCM not available for card sof-hda-dsp Nov 30 11:33:11 ortiz pulseaudio[24457]: Parsing configuration file '/usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf'

Hmm, what if that package is just not installed at all? Looking at the package in sid, the above files should be there: https://packages.debian.org/sid/all/alsa-ucm-conf/filelist

(Should I create a separate issue for that?)

No need, let's rootcause the problem under this bug.

paulmenzel commented 3 years ago

Hmm, what if that package is just not installed at all?

And it was not installed. After installing it, the user reported, it works now. Thank you very much.

(Re-reading all the issue comment, I am sorry, for dropping the ball, and only checking what version Debian packages and not if it is installed. My fault and should we ever see each other on a conference, I owe you and Pierre-Louis a beverage.)

kv2019i commented 3 years ago

Ok great! :) And no worries @paulmenzel ! UCM is an old feature of ALSA, but it hasn't really been mandatory for many mainstream hw configs, so we've had lots of integration issues in ALSA, Pulseaudio and in kernel side. It is starting to look better now, but I'm still interested in any problems like the one you reported.

It's a bit suprising the package was not installed. I see Pulseaudio and various other packages depending on libasound2 and recommending various other packages, but not sure how alsa-ucm-conf is pulled into default installs. Hmm. This is a potential gap as increasing amount of systems are going to depend on alsa-ucm-conf to be there for working audio support.

paulmenzel commented 3 years ago

For example libasound2-data recommends alsa-ucm-conf. No idea, if this should be made a dependency. Probably not for older systems where it’s needed.

No idea, what a good way forward is.

A start would be to make it an error messages in PulseAudio, so that it shows up in the logs without having the debug level set to debug.

plbossart commented 3 years ago

PulseAudio should require alsa-ucm-conf, that'd be a better dependency IMHO.

kv2019i commented 3 years ago

Hmm @plbossart , that would still leave others apps out-of-luck. I think this should really be part of the ALSA driver dependencies in user-space.

plbossart commented 3 years ago

@kv2019i what other apps? I am not aware of any other application using UCM, only PulseAudio and CRAS use it today.

kv2019i commented 3 years ago

@plbossart OK, a fair point. :) But that's more of an adoption issue. Other apps should be using UCM, and with more and more cards coming where UCM is critical to actually get sound out, this becomes more pressing. If UCM only gets installed via pulseuaudio, this will not help in adoption as it suggests this is something only audio servers use.

@perexg How do you handle this in Fedora? I.e. how is alsa-ucm-conf pulled into the installation?

perexg commented 3 years ago

@perexg How do you handle this in Fedora? I.e. how is alsa-ucm-conf pulled into the installation?

It's in the multimedia group together with pulseaudio so both are tied together for the installation (not packaging). We also think to add strong alsa-lib dependency on the alsa-ucm-conf (packaging), because it seems that we need this also for some USB and HDA hardware (not only SOF related) and the recent UCM changes (BootSequence) replaces the legacy soundcard initialization.

plbossart commented 3 years ago

@paulmenzel closing but I'll still take you up on your offer to buy me and @kv2019i a beverage.

thesofproject / linux

[BUG] TGL Dell XPS 13 9310: Microphone/input does not work #2577