On Sat, 11 Feb 2023 09:38:47 +0100, Mike FABIAN wrote:
And now I rebooted again after yet another kernel update (I did not change anything apart from "sudo dnf update" and reboot).
Now it is working again. I have attached the output of alsa-info.sh for the non-working case.
Could it be that the kernel update had nothing to do with it working now and that it switches between working and not working "randomly" when rebooting?
Well, it's hard to tell... If it's broken silently (literally, no error log reported), that's likely some issue of the driver (either graphics or HDMI-audio). OTOH, if you see any relevant error/warning log from pipewire or the kernel driver, it'd be more about the inconsistency in the configuration.
Takashi
Mike FABIAN mfabian@redhat.com さんはかきました:
Now it suddenly stopped working again after a reboot although I did not change anything with the module options.
The output of alsa-info.sh for the non-working state I have now is attached.
Takashi Iwai tiwai@suse.de さんはかきました:
Please check /proc/asound/card0/eld#* (for the card number 0, as found in /proc/asound/cards as sof-hda-dsp). One of them should have a valid ELD entry. This is the first step. If no proper monitor and ELD is found in those, something wrong at the detection in the kernel.
$ cat /proc/asound/card0/eld#2.21 monitor_present 1 eld_valid 1 codec_pin_nid 0xc codec_dev_id 0x1 codec_cvt_nid 0x3 monitor_name LG ULTRAFINE connection_type DisplayPort eld_version [0x2] CEA-861D or below edid_version [0x3] CEA-861-B, C or D manufacture_id 0x6d1e product_id 0x5bc2 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x1] FL/FR sad_count 1 sad0_coding_type [0x1] LPCM sad0_channels 2 sad0_rates [0xe0] 32000 44100 48000 sad0_bits [0xe0000] 16 20 24 mfabian@hathi:~ $
That is OK, right?
$ cat /proc/asound/cards 0 [sofhdadsp ]: sof-hda-dsp - sof-hda-dsp LENOVO-20WNS1F81R-ThinkPadT14sGen2i 1 [USB ]: USB-Audio - ThinkPad Thunderbolt 3 Dock USB Lenovo ThinkPad Thunderbolt 3 Dock USB at usb-0000:52:00.0-2.1.1.2, full speed $
The next is to test aplay directly with the device. "aplay -L" will show the possible option, and you can try like
% apaly -Dhdmi:CARD=xxx,DEV=x -vv foo.wav
for a WAV file in a format matching with the supported device (typically 2 channel stereo 44.1kHz or 48kHz 16 or 32bit format). If this gets a busy error, stop wireplumber once during the test: % systemctl --user stop wireplumber % aplay .... % systemctl --user start wireplumber
If the aplay test doesn't work, again, it means that there's something wrong in the kernel.
$ file /usr/share/ibus-typing-booster/data/coin9.wav /usr/share/ibus-typing-booster/data/coin9.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz mfabian@hathi:~ $ aplay -Dhdmi:CARD=sofhdadsp,DEV=0 -vv /usr/share/ibus-typing-booster/data/coin9.wav ALSA lib conf.c:5671:(snd_config_expand) Unknown parameters CARD=sofhdadsp,DEV=0 ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM hdmi:CARD=sofhdadsp,DEV=0 aplay: main:831: audio open error: 無効な引数です
I don’t know what that means.
[...]
That might explain. There were a few fixes about HDMI HD-audio stuff recently.
-- Mike FABIAN mfabian@redhat.com 睡眠不足はいい仕事の敵だ。