Speakers unavailable and no microphone detected for Dell Latitude 9440

[lnchan]

Bug description

There is no speaker audio, and the microphone is not recognised.

The PulseAudio volume control panel shows the speakers as "unavailable", and no input device (of which there should be one).

Reproducing

A fresh install of Fedora 40 (currently Beta). Bug also exists under linux-next-20240403, or SOF firmware/topology files from the 2024.03 release.

Environment

• Device: Dell Latitude 9440.
• SoC: Intel Alder Lake platform (Intel Core i5-1345U)
• Kernel: linux-next-20240403
• sof-bin: 2024.03
• Fedora 40 Beta

Attachments

• alsa-info.txt

---

Please tell me if there's anything else you would need to debug this issue!

I've tried snd_soc_sof_sdw quirk=0x2022 and snd-intel-sdw-acpi sdw_link_mask=0x7, but the only differences that made were proper "plugged-in" detection for the audio jack, and making the speakers show as "available" but with no output. The audio jack works for external audio output.

I've added the sof-dyndbg.conf attached here in hopes of making the issue clearer; but it doesn't look like the firmware is failing to load in any way.

arecord -l does show both a jack in and microphone device, but they seem unusable.

[plbossart]

The dmesg log and alsa-info don't show any problems, a card is created and everything looks fine.

The configuration reported by amixer is "cfg-spk:2 cfg-amp:2 hs:rt711-sdca spk:rt1318 mic:rt715-sdca", nothing surprising.

I would try with a terminal to see if you get any sound with this:

alsaucm -c sof-soundwire set _verb HiFi set _enadev Speaker
speaker-test -Dhw:0,2 -c2 -r48000 -FS16_LE -t sine

[lnchan]

That does work! (it did require installing alsa-ucm-conf files which do not seem part of the Fedora packages somehow?)
I'm not sure why the device is shown as unavailable over Pipewire's Pulseaudio implementation... But I guess that must mean it's a Pipewire bug, if it works under ALSA?

Thank you!

[plbossart]

yes, the configuration is reported with the amixer component string above, and then UCM files have conditional statements to apply the right mixer settings.

If PipeWire/userspace is not detecting all of this, then it's clearly a bug on their side.

I am surprised however that UCM files are not included in Fedora, usually that's the one distribution that has all the latest UCM stuff. Adding @perexg for comments.

[perexg]

@lnchan : Fedora has alsa-ucm package not alsa-ucm-conf and this package should be installed by default for the Fedora Workstation edition.

[lnchan]

@lnchan : Fedora has alsa-ucm package not alsa-ucm-conf and this package should be installed by default for the Fedora Workstation edition.

I installed alsa-ucm-utils manually here (via dnf) as it wasn't installed when I tried to run the provided commands; but those commands were failing (complaining about configuration, mostly). I remembered about alsa-ucm-conf, installed the files from the Git repo, and then those commands worked.

After a reboot and those configuration files and packages installed, the devices are now detected and speaker audio works as expected (the microphone is currently detected but not working).

It is a completely-standard Fedora Workstation 40 Beta install from two days ago (with a freshly downloaded ISO); so I'm not sure how I ended up not having those files...

---

yes, the configuration is reported with the amixer component string above, and then UCM files have conditional statements to apply the right mixer settings.

If PipeWire/userspace is not detecting all of this, then it's clearly a bug on their side.

I am surprised however that UCM files are not included in Fedora, usually that's the one distribution that has all the latest UCM stuff. Adding @perexg for comments.

Adding those ucm-conf files and installing alsa-ucm-utils fixed the issue for audio output it seems! Pipewire now detects it properly and outputs properly, and input devices are detected. That helps so much, thanks a lot!

It now somehow detects the jack-in microphone as "plugged-in" even though it isn't, and there seems to be no microphone input either.

[lnchan]

I followed diagnostic information on #4881 (as it looked familiar to my issue: microphone detected, no audio). Using options snd_sof_intel_hda_common dmic_num=4 fixed the built-in microphone input (on top of the above). The jack-in microphone still detects as "plugged-in", which could probably be fixed with another modprobe option (the ones I tried just removed all input devices).

I'll do a bit more testing and try to get a minimum set of needed action of a fresh Fedora Workstation 40 beta install.

Thanks everyone for the help!

[plbossart]

no, that can't possibly work.

dmic_num=4 is only relevant when the digital microphones are connected to the Intel chip, but in the Dell configurations the microphones are attached to the rt715-sdca external chip.

[lnchan]

no, that can't possibly work.

dmic_num=4 is only relevant when the digital microphones are connected to the Intel chip, but in the Dell configurations the microphones are attached to the rt715-sdca external chip.

I did check again: I did comment it, and it indeed still works. But I'm very confused as to why it didn't before, since I never changed anything in-between? (I'm not very familiar with audio hardware as you might notice)

I'm sure it looks like erratic end-user behaviour on your end 😅 I'll try to do a fresh reinstall ASAP to clarify things up as much as I can.

EDIT: the only thing I can think of right now is that it started working via ALSA before it started working via Pipewire. I did stop pipewire.service + pipewire.socket to check microphone input, and it must've changed the environment somehow in a way that reboots haven't.

[lnchan]

Fresh reinstall on Fedora 40 Beta; the audio output works by updating alsa-ucm-conf files to the Git repo's latest main branch commit version and rebooting. No other changes were made.

I tried looking for a newer alsa-ucm Fedora package than what was installed, but it seems that's the latest package for Fedora; I'm assuming that whatever makes it work was added since the last package version (January 2024 or so).

However, the microphone isn't working quite yet since the reinstall. It shows itself as present but no audio seems to be coming through (arecord -c2 on the device results in pure silence, nothing shown on Tenacity's spectrogram either).

Hope this helps in some way (though so far, this seems unrelated to SOF drivers or firmware... sorry!)
Thank you both for the help, again!

---

For reference, here is the alsa-info.sh dump for the current installation (with the above steps) on the device (non-working microphone input, working audio output, jack-in still wrongly detected as plugged-in).

[plbossart]

@lnchan Can you try to use this patch https://github.com/thesofproject/linux/commit/f77b81d8e66bc410f66933502d6f9eccd40afc63.patch to see if this solves your jack detection issue? Thanks!

[lnchan]

Hi !

Just tried this patch (applied it to the latest F40 kernel sources, rebuilt a RPM and installed it); the jack detection does seem to work! Plugging and unplugging a device changes the state to the correct value now! :)
Thank you very much for your help and your patches (in general, not just for this device!)

I still haven't figured out what made the microphone work from before. So far, it's not working on the current install. I was thinking it would be the SOF firmware binaries, but the F40 package that's installed matches the latest GitHub release; so it must be another difference between the two installs (could be a kernel difference..? but it feels unlikely somehow.)

---

As usual, here's the latest alsa-info.sh dump for the current installation with the above kernel patch (no microphone input, working audio output, working jack detection).

[plbossart]

For the microphone, I would open a terminal and try this:

arecord -Dhw:0,4 -c2 -r48000 -fS16_LE

if don't see anything on the screen, the recording is silent likely due to some mixer issues.

Usually UCM fixes everything, but I see in your alsa-info things that are a bit surprising:

control.48 {
iface MIXER
name 'PGA2.0 2 Master Capture Switch'
value.0 false
value.1 false

Try to turn on all the 'switch' mixers on capture to 'on'.

amixer -Dhw:0 cset numid=48 on

and see what happens. Repeat this for the the PGA capture stuff, I don't know why they are off.

The last possibility is that the dmics are not connected to the 'right' interface no RT714, but that would need to be diagnosed by @shumingfan and @jack-cy-yu at Realtek.

[lnchan]

For the microphone, I would open a terminal and try this:

arecord -Dhw:0,4 -c2 -r48000 -fS16_LE

if don't see anything on the screen, the recording is silent likely due to some mixer issues.
To confirm, microphone tests I've done followed this (as per your recommendations on other issues) :)

Usually UCM fixes everything, but I see in your alsa-info things that are a bit surprising:

control.48 { iface MIXER name 'PGA2.0 2 Master Capture Switch' value.0 false value.1 false

Try to turn on all the 'switch' mixers on capture to 'on'.

amixer -Dhw:0 cset numid=48 on

and see what happens. Repeat this for the the PGA capture stuff, I don't know why they are off.

The last possibility is that the dmics are not connected to the 'right' interface no RT714, but that would need to be diagnosed by @shumingfan and @jack-cy-yu at Realtek.

I get nothing on any of them; except one that I can only notice thanks to pavuctl. It seems that numid=52 (PGA5.0 5 Master Capture Switch) makes the input ever-so-slightly noisy (but no audio, as far as I can tell). Having all of them enabled at the same time also makes no difference in that regard.
I'm not sure how I got it working the first time (and I realise too late I should've posted an alsa-info.sh of when I did before I wiped... oops)

Thanks a lot, again!

[lnchan]

Update again: I got the microphone working as a side-effect in trying to reset the amixer changes.
I stopped alsa-state.service, deleted the ALSA state file, rebooted; and the microphone input now works.
I'm not sure how it came into such a state in the first place, however (considering I didn't tinker with it or amixer until now).

Here is the latest alsa-info.txt for reference. I hope it can be useful in some way!

Nevertheless, thank you, all of my issues are now fixed thanks to your help! :) Sorry for the trouble!

[plbossart]

your configuration did look bad indeed. The 'feature' of the asound.state file is that it keeps your settings for the next boot, but if those settings are bad for some reason there's no good way to know. Removing this bad state is the only way to solve those issues.

[lnchan]

I can't thank you enough for your help :) I hope this issue will at least serve as a sort of reference for anyone experiencing this problem on this specific hardware!

I guess I'll be closing the issue since technically, everything works as expected on the kernel side of things, especially since your hw quirk patch :) (just not quite yet on the out-of-the-box Fedora 40 ALSA, but I'm sure it's gonna be working perfectly fine out-of-the-box within a few package updates!)