Closed paulmenzel closed 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:
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:
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
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
@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:
In any case, looks like a kernel bug, so moving to kernel and assigning to myself.
@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?
@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 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.
@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
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.
@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 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.
[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.
@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 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?)
@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.
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.)
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.
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
.
PulseAudio should require alsa-ucm-conf, that'd be a better dependency IMHO.
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.
@kv2019i what other apps? I am not aware of any other application using UCM, only PulseAudio and CRAS use it today.
@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 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.
@paulmenzel closing but I'll still take you up on your offer to buy me and @kv2019i a beverage.
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.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 todmesg
.]. Also, an excerpt from the Linux messages: