Created attachment 307442 [details] My alsa-info Since the AVS driver replaced SST driver starting from kernel 6.12: https://lore.kernel.org/lkml/87wmje9oav.wl-tiwai@suse.de/, it's now impossible to use DMIC on the device (DMIC only works with the SST driver). The default configuration without options snd-intel-dspcfg dsp_driver=2 specified in /etc/modprobe.d/snd-intel.conf will load the AVS driver. With kernel 6.12+, options snd-intel-dspcfg dsp_driver=2 is redirected to the AVS driver. The problem is the AVS driver is not working at all in this device, i.e. no sound output and input. I have reported this issue in SUSE's Bugzilla #1234987: https://bugzilla.suse.com/show_bug.cgi?id=1234987. It seems someone is able to make the AVS driver work with ALC255: https://github.com/thesofproject/avs-topology-xml/issues/27#issuecomment-2477512555.
Hi, Few questions: Do you have UCM files on your system? # /usr/share/alsa/ucm2/Intel/avs/ Can you provide NHLT ACPI table from your system? # cat /sys/firmware/acpi/tables/NHLT > NHLT.bin Additionally can you try starting recording manually with arecord? # arecord -Dhw:avsdmic,2 -r 48000 -c4 -f S32_LE -vvv > /dev/null # arecord -Dhw:avsdmic,2 -r 48000 -c4 -f S16_LE -vvv > /dev/null # arecord -Dhw:avsdmic,2 -r 48000 -c2 -f S32_LE -vvv > /dev/null # arecord -Dhw:avsdmic,2 -r 48000 -c2 -f S16_LE -vvv > /dev/null # arecord -Dhw:avsdmic,2 -r 16000 -c4 -f S32_LE -vvv > /dev/null # arecord -Dhw:avsdmic,2 -r 16000 -c4 -f S16_LE -vvv > /dev/null # arecord -Dhw:avsdmic,2 -r 16000 -c2 -f S32_LE -vvv > /dev/null # arecord -Dhw:avsdmic,2 -r 16000 -c2 -f S16_LE -vvv > /dev/null and report if any of above worked?
> Do you have UCM files on your system? > # /usr/share/alsa/ucm2/Intel/avs/ I have these directories in /usr/share/alsa/ucm2/Intel/avs/: avs_da7219 avs_max98357a avs_max98927 avs_rt5514 avs_ssm4567 avs_dmic avs_max98373 avs_nau8825 avs_rt5663 hdaudioB0D2 Each of them contains .conf files, for example, avs_dmic contains: DMIC-2ch.conf DMIC-2ch-HiFi.conf DMIC-4ch.conf DMIC-4ch-HiFi.conf I'm not sure whether these are UCM files. > Additionally can you try starting recording manually with arecord?... and > report if any of above worked? Only this line works: arecord -Dhw:avsdmic,2 -r 48000 -c2 -f S16_LE -vvv > /dev/null I also save the recorded sound to output.wav, but the file is silent.
Created attachment 307450 [details] My NHLT.bin file. > Can you provide NHLT ACPI table from your system? > # cat /sys/firmware/acpi/tables/NHLT > NHLT.bin
Created attachment 307452 [details] [PATCH] [WIP] ASoC: Intel: avs: Constrain path based on BE Can you test attached patch? It should constrain FE to limit it to use only supported formats.
@Archer, a test kernel with the patch in comment 4 is being built in OBS home:tiwai:bsc1234987 repo. Once after the build finishes, the test kernel package will be available later at https://download.opensuse.org/repositories/home:/tiwai:/bsc1234987/standard/
@Takashi, thanks. I disabled secure boot and tested the patched kernel. The kernel is Linux 6.12.8-1.g69d9ba9-default. @Amadeusz, the patch doesn't make the sound output and sound input (from DMIC) works on my system. I also checked that the AVS driver is loaded and being used.
Created attachment 307453 [details] My alsa-info after patching with Linux 6.12.8-1.g69d9ba9-default.
Yes, that seems a lot better, DMIC has volume control, so you may need to adjust it to record anything. To enable it in GUI, you probably need to link UCM files: # cd /usr/share/alsa/ucm2/conf.d/avs_dmic/ # ln -s ../../Intel/avs/avs_dmic/DMIC-2ch.conf KBL-SwiftSF514_52T-V1.11-Carlsberg_KL.conf and reboot, if I got name of machine right from your alsa-info, then you should be able to use volume slider in audio settings.
And as for HDA playback can you check if adding following files with content, helps: # cat /usr/share/alsa/ucm2/Intel/avs/hdaudioB0D0/hdaudioB0D0.conf Syntax 6 SectionUseCase."HiFi" { File "/Intel/avs/hdaudioB0D0/hdaudioB0D0-HiFi.conf" Comment "Play HiFi quality Music" } # cat /usr/share/alsa/ucm2/Intel/avs/hdaudioB0D0/hdaudioB0D0-HiFi.conf Include.analog.File "/HDA/HiFi-analog.conf" And add link using: # cd /usr/share/alsa/ucm2/conf.d/hdaudioB0D0/ # ln -s ../../Intel/avs/hdaudioB0D0/hdaudioB0D0.conf hdaudioB0D0.conf and similarly it would be best to reboot to make sure those configs were loaded.
@Amadeusz, thanks. > To enable it in GUI, you probably need to link UCM files: > # cd /usr/share/alsa/ucm2/conf.d/avs_dmic/ > # ln -s ../../Intel/avs/avs_dmic/DMIC-2ch.conf > KBL-SwiftSF514_52T-V1.11-Carlsberg_KL.conf After doing this, my DMIC works now! I'm able to see it in my audio settings just like you said. I also checked the record sound. It works, but the volume is low (like it was with the SST driver). --- As for the HDA playback (my device's speakers). I don't have /usr/share/alsa/ucm2/Intel/avs/hdaudioB0D0 directory. Here are the directories I have at /usr/share/alsa/ucm2/Intel/avs/ avs_da7219 avs_max98357a avs_max98927 avs_rt5514 avs_ssm4567 hdaudioB0D2 avs_dmic avs_max98373 avs_nau8825 avs_rt5663 So, I created a new hdaudioB0D0 directory. And I created 2 new files inside the directory: hdaudioB0D0.conf and hdaudioB0D0-HiFi.conf with the contents you provided. I don't have /usr/share/alsa/ucm2/conf.d/hdaudioB0D0/ directory either. So, I created a new hdaudioB0D0 directory here. Then, I add link as per suggested. After that, I rebooted. But my speakers still don't work. --- Additionally, I also test HDMI audio output. It's working without any issue! This is the first time that HDMI audio and DMIC work together on my device.
Created attachment 307462 [details] My alsa-info with DMIC and HDMI audio working, but the speakers still don't work.
Seems like you are using pipewire, I'm not really familiar how to debug issues with it. @Takashi do you have some instructions how to check if pipewire loads and parses UCM files? Overall I'm pretty sure that we should be able to just reuse HDA UCM files, as we just use codecs created by shared code, so controls should be same. That's what we are doing with HDMI and as mentioned by @Archer it works.
It's better to test directly with `alsaucm -c hw:0 dump text` . Anyway, looking again to AVS configs, it would be much better to add back "components" support to AVS drivers (I think that SST drivers did that) instead linking all hardware variants using card long name. Look to "${CardComponents}" string in UCM configurations and "card->components" modifications in sound/sof/intel/boards tree. The idea behind is to pass "already known" information from the driver to the user space.
The above comment was targeted to DMIC support.
@Archer And indeed it doesn't load. Try with updated file content: # cat /usr/share/alsa/ucm2/Intel/avs/hdaudioB0D0/hdaudioB0D0-HiFi.conf Define.DeviceMic "Mic" Include.analog.File "/HDA/HiFi-analog.conf" @Jaroslav When it comes to DMIC, with patch from comment #4 there will be no need to differentiate number of channels, as kernel constrain takes care of that and we can use one file everywhere. Does it sound reasonable?
@Amadeusz > Seems like you are using pipewire Yes, I'm using PipeWire. > Try with updated file content: > > # cat /usr/share/alsa/ucm2/Intel/avs/hdaudioB0D0/hdaudioB0D0-HiFi.conf > Define.DeviceMic "Mic" > > Include.analog.File "/HDA/HiFi-analog.conf" I updated the file content as per suggested. My speakers still don't work. There's no entry in the GUI settings, the same as before.
Created attachment 307475 [details] My alsa-info updating as per suggested in comment #15, working DMIC and HDMI, speakers don't work.
@Jaroslav I'm trying to work it out locally, but I'm of ideas on how to reuse HDA UCMs, do you have any suggestion? With the one from comment #15 it seems to load (confirmed by: alsaucm -c hw:0 dump text), but there is no endpoints present in GUI.
I think that we should move discussion to UCM issue tracker: https://github.com/alsa-project/alsa-ucm-conf/issues (or create a PR) You should grab the errors from the pipewire. Usually, the PCM device cannot be accessed for a reason (unaccepted stream parameters or so). You may use `spa-acp-tool` or wireplumber debugging [1] to look for the reason. [1] https://julian.pages.freedesktop.org/wireplumber/daemon/logging.html BTW: I don't understand, why AVS audio driver advertises some hardware address (hdaudioB%dD%d in sound/soc/intel/avs/core.c) to upper layer (driver name). It's clumsy. We have other ways to export this and with multiple codecs attached, it's even worse. The driver name should be something like 'HDA-AVS' or so like we have for legacy HDA (HDA-Intel). BTW2: Also, it's preferred to merge standalone DMIC card to the HDA profile as we do for AMD ACP/HDA and SOF-HDA drivers to keep internal sound hardware in one logical profile (also for device priority management).
Thanks, I've opened draft PR: https://github.com/alsa-project/alsa-ucm-conf/pull/499 I've tried with `spa-acp-tool`, but didn't see anything broken, output in above PR. RE BTW: We did it this way, as this was done same way in Skylake driver and we wanted to stay compatible as much as it was possible, to cause less problems from end users. RE BTW2: We kept DMIC configuration as separate UCM file as it is also used on devices which don't use HDA codec but I2S one. I'm not opposed to somehow joining the UCM files, as long as it keeps working on other devices.
> RE BTW: We did it this way, as this was done same way in Skylake driver and > we wanted to stay compatible as much as it was possible, to cause less > problems from end users. I doubt. It seems that SST drivers were using 'hda-dsp' string in the driver name: https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/Intel/hda-dsp I would also appreciate, if you can help me to identify the older SST configs (driver names) to move them to ucm2/Intel/sst subtree.
> RE BTW2: We kept DMIC configuration as separate UCM file as it is also used > on devices > which don't use HDA codec but I2S one. I'm not opposed to somehow joining the > UCM files, > as long as it keeps working on other devices. It's not a problem to add this mechanism to all affected combos, but I'd like to know the real list (avs dmic + other avs driver) to make ucm changes.
(In reply to Jaroslav Kysela from comment #21) > > RE BTW: We did it this way, as this was done same way in Skylake driver and > > we wanted to stay compatible as much as it was possible, to cause less > > problems from end users. > > I doubt. It seems that SST drivers were using 'hda-dsp' string in the driver > name: > > https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/Intel/hda-dsp > Indeed, it seems so. While we are not entirely opposed to such change, we are still discussing it, as it changes card name, which will break backward compatibility for existing users of avs driver. > I would also appreciate, if you can help me to identify the older SST > configs (driver names) to move them to ucm2/Intel/sst subtree. When it comes to SST UCMs, there is not much of them upstream: https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/Intel/broxton-rt298 https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/Intel/skylake-rt286 https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/Intel/hda-dsp
(In reply to Amadeusz Sławiński from comment #23) > (In reply to Jaroslav Kysela from comment #21) > > > RE BTW: We did it this way, as this was done same way in Skylake driver > and > > > we wanted to stay compatible as much as it was possible, to cause less > > > problems from end users. > > > > I doubt. It seems that SST drivers were using 'hda-dsp' string in the > driver > > name: > > > > > https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/Intel/hda-dsp > > > > Indeed, it seems so. While we are not entirely opposed to such change, we > are still discussing it, as it changes card name, which will break backward > compatibility for existing users of avs driver. If you think that this change breaks something (Google?), just add new CONFIG_ kernel configuration option which will keep the current name by default, but it will allow to use new name for upstream UCM. Thanks.