alsa-project / alsa-ucm-conf

ALSA Use Case Manager configuration
BSD 3-Clause "New" or "Revised" License
76 stars 216 forks source link

mic not working on Dell xps 13 9340 (2024) #425

Closed neyb closed 4 months ago

neyb commented 4 months ago

Hello,

The version 1.2.12 seems to fix the speaker of the xps 13 9430 (2024), but there seems to still be a problem on the integrated microphone, the mic appears but their seems to be no sound recorded : 

❯ amixer -c 0 info
Card sysdefault:0 'sofsoundwire'/'Intel Soundwire SOF'
  Mixer name    : 'Intel Meteor Lake HDMI'
  Components    : 'HDA:8086281d,80860101,00100000 cfg-spk:2 cfg-amp:2 spk:rt1318 mic:rt715-sdca'
  Controls      : 40
  Simple ctrls  : 19
❯ lspci
0000:00:00.0 Host bridge: Intel Corporation Device 7d01 (rev 04)
0000:00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P [Intel Arc Graphics] (rev 08)
0000:00:04.0 Signal processing controller: Intel Corporation Meteor Lake-P Dynamic Tuning Technology (rev 04)
0000:00:05.0 Multimedia controller: Intel Corporation Meteor Lake IPU (rev 04)
0000:00:06.0 System peripheral: Intel Corporation RST VMD Managed Controller
0000:00:07.0 PCI bridge: Intel Corporation Meteor Lake-P Thunderbolt 4 PCI Express Root Port #0 (rev 10)
0000:00:07.3 PCI bridge: Intel Corporation Meteor Lake-P Thunderbolt 4 PCI Express Root Port #3 (rev 10)
0000:00:08.0 System peripheral: Intel Corporation Meteor Lake-P Gaussian & Neural-Network Accelerator (rev 20)
0000:00:0a.0 Signal processing controller: Intel Corporation Meteor Lake-P Platform Monitoring Technology (rev 01)
0000:00:0b.0 Processing accelerators: Intel Corporation Meteor Lake NPU (rev 04)
0000:00:0d.0 USB controller: Intel Corporation Meteor Lake-P Thunderbolt 4 USB Controller (rev 10)
0000:00:0d.2 USB controller: Intel Corporation Meteor Lake-P Thunderbolt 4 NHI #0 (rev 10)
0000:00:0d.3 USB controller: Intel Corporation Meteor Lake-P Thunderbolt 4 NHI #1 (rev 10)
0000:00:0e.0 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller Intel Corporation
0000:00:12.0 Serial controller: Intel Corporation Meteor Lake-P Integrated Sensor Hub (rev 20)
0000:00:14.0 USB controller: Intel Corporation Meteor Lake-P USB 3.2 Gen 2x1 xHCI Host Controller (rev 20)
0000:00:14.2 RAM memory: Intel Corporation Device 7e7f (rev 20)
0000:00:15.0 Serial bus controller: Intel Corporation Meteor Lake-P Serial IO I2C Controller #0 (rev 20)
0000:00:15.2 Serial bus controller: Intel Corporation Meteor Lake-P Serial IO I2C Controller #2 (rev 20)
0000:00:16.0 Communication controller: Intel Corporation Meteor Lake-P CSME HECI #1 (rev 20)
0000:00:1c.0 PCI bridge: Intel Corporation Device 7e3f (rev 20)
0000:00:1e.0 Communication controller: Intel Corporation Meteor Lake-P Serial IO UART Controller #0 (rev 20)
0000:00:1f.0 ISA bridge: Intel Corporation Device 7e02 (rev 20)
0000:00:1f.3 Multimedia audio controller: Intel Corporation Meteor Lake-P HD Audio Controller (rev 20)
0000:00:1f.4 SMBus: Intel Corporation Meteor Lake-P SMBus Controller (rev 20)
0000:00:1f.5 Serial bus controller: Intel Corporation Meteor Lake-P SPI Controller (rev 20)
0000:71:00.0 Network controller: Intel Corporation Wi-Fi 7(802.11be) AX1775*/AX1790*/BE20*/BE401/BE1750* 2x2 (rev 1a)
10000:e0:06.0 PCI bridge: Intel Corporation Device 7e4d (rev 20)
10000:e1:00.0 Non-Volatile memory controller: Micron Technology Inc 2550 NVMe SSD (DRAM-less) (rev 01)
❯ arecord -l
**** Liste des périphériques matériels CAPTURE ****
carte 0 : sofsoundwire [sof-soundwire], périphérique 3 : Amp feedback (*) []
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : sofsoundwire [sof-soundwire], périphérique 4 : Microphone (*) []
  Sous-périphériques : 0/1
  Sous-périphérique #0 : subdevice #0
plbossart commented 4 months ago

We've supported the rt715-sdca for about 2 years now, it's rather odd that it's not detected.

Can you please attach the full 'alsa-info' log?

@bardliao @jack-cy-yu FYI

neyb commented 4 months ago

here is the file : alsa-info.txt

jack-cy-yu commented 4 months ago

@neyb Please use "cat /sys/kernel/debug/regmap/sdw-addr/registers" to dump registers while recording. And for "sdw-addr", there are "sdw:xxxxxx" and "sdw:xxxxxx-sdw-mbq", we need both dumps. Thanks.

supperrabbit88 commented 4 months ago

My system is pre-installed with Fedora-Workstation-Live-x86_64-40-20240419.n.0.iso The alsa-ucm is with alsa-ucm-1.2.11-2.fc40. The built-in speaker and MIC do not work.

Pick follow files from current master branch, then the built-in speaker and MIC are are worable. https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/sof-soundwire/rt1318.conf https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/sof-soundwire/sof-soundwire.conf https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/sof-soundwire/HiFi.conf https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/common/pcm/hdmi.conf

@neyb you may have a try to pull the latest UCM config

perexg commented 4 months ago

@neyb: Updated alsa-ucm package is in stable since yesterday: https://bodhi.fedoraproject.org/updates/FEDORA-2024-0514b78147

Just upgrade...

neyb commented 4 months ago

Sorry I wasn't around for a while, I'm gonna give you the dumps soon (and also test last version)

neyb commented 4 months ago

I've updated my system and ucm-conf has not been updated for few days (last update was 1.2.12-1, built the 2024-06-12 at 20:24 UTC by the package maintainer). before this update I had totally no sound, but now only the mic is malfunctionning : I can get last master if needed.

@jack-cy-yu here are the dumps : dumps and record.zip. I made the record using the command arecord -d 5 test.wav

@supperrabbit88 the fact you don't have the problem with another dist (I'm on arch...) might indicate the problem is not ucm-conf itself... You got a xps 13 9340 ?

jack-cy-yu commented 4 months ago

@neyb From the dumps, built-in MIC should be switched to DMIC3/4, but it's switched to MIC1/2. Something wrong with your ucm.

perexg commented 4 months ago

The mics are set in BootSequence. Please, remove the ALSA state file:

systemctl stop alsa-state
rm /var/lib/alsa/asound.state
systemctl start alsa-state

... and relogin to apply new UCM configuration.

neyb commented 4 months ago

I did what @perexg advise me to (except I was using alsa-restore and not alsa-state)... And it, ok it seems to work fine now... Thanks.

Any idea how I fall in this bad mic configuration ?

Is there anything you need to do or I can close this issue ?

plbossart commented 4 months ago

wondering if ArchLInux has a setup that's wrong, we've seen other reports such as https://wiki.archlinux.org/title/Dell_XPS_17_(9720)#Microphone where DMIC1 was used.

perexg commented 4 months ago

The issue was that the BootSequence is applied only when the state file does not exist. So if you booted with a system with a wrong or non-existent UCM preset (driver defaults are saved) those values may not match your hardware. We should document this probably somewhere to clear the state when the user encounters a problem at first.

Added to c1920e95d476c33f4b43484f14c36149829e514a .

neyb commented 4 months ago

I've notice the problem to come back on reboots... I have to rerun the

systemctl stop alsa-restore
rm /var/lib/alsa/asound.state
systemctl start alsa-restore

Every time... Any idea where this could come from ?

neyb commented 4 months ago

from what I understand, because I have no /etc/alsa/state-daemon.conf file, the used systemd service is alsa-restore (and not alsa-state).

https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture#ALSA_and_systemd

@perexg maybe this issue should be reopened ?

perexg commented 4 months ago

The alsa-restore service works only when udev rules exists like /lib/udev/rules.d/90-alsa-restore.rules:

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", RUN+="/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main restore /dev/$name"
TEST=="/etc/alsa/state-daemon.conf", RUN+="/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main nrestore /dev/$name"

LABEL="alsa_restore_end"

It's distribution job to create such rules.

To clarify: The ASoC drivers may delay initialization, thus the driver may be loaded later then the alsa-restore service is started. In this case, udev rules must handle this situation.

neyb commented 4 months ago

Ok I'll post a thread on arch forum then... And maybe an issue somewhere else thx.