No sound on HDMI by default on Lenovo T14s using Fedora 37
With a Lenovo Thinkpad T14s (Gen1, Intel version), I tried to get sound on the monitor speakers via the HDMI cable.
It didn’t work out of the box and after a bit of googling I found:
https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T-series-Laptops/T...
which suggested to put
snd_rn_pci_acp3x.dmic_acpi_check=0
on the kernel command line.
So I tried this:
$ cat /etc/modprobe.d/lenovot14s.conf options snd-rn-pci-acp3x dmic_acpi_check=0
And that did make it work indeed.
I have no idea what this means and why this makes it work.
On Wed, 18 Jan 2023 16:30:53 +0100, Mike FABIAN wrote:
With a Lenovo Thinkpad T14s (Gen1, Intel version), I tried to get sound on the monitor speakers via the HDMI cable.
It didn’t work out of the box and after a bit of googling I found:
https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T-series-Laptops/T14s-AMD-no-HDMI-audio-on-Linux/m-p/5081195?page=2which suggested to put
snd_rn_pci_acp3x.dmic_acpi_check=0on the kernel command line.
So I tried this:
$ cat /etc/modprobe.d/lenovot14s.conf options snd-rn-pci-acp3x dmic_acpi_check=0
And that did make it work indeed.
I have no idea what this means and why this makes it work.
The option basically should influence on the driver's behavior whether to probe the built-in d-mic or not, and it has no direct relationship with HDMI (supposedly via HD-audio bus), so it's puzzling how this fixes the problem.
Could you run alsa-info.sh (with --no-upload option) on both working and non-working cases, and attach both outputs for comparison?
thanks,
Takashi
Takashi Iwai tiwai@suse.de さんはかきました:
On Wed, 18 Jan 2023 16:30:53 +0100, Mike FABIAN wrote:
With a Lenovo Thinkpad T14s (Gen1, Intel version), I tried to get sound on the monitor speakers via the HDMI cable.
It didn’t work out of the box and after a bit of googling I found:
https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T-series-Laptops/T14s-AMD-no-HDMI-audio-on-Linux/m-p/5081195?page=2which suggested to put
snd_rn_pci_acp3x.dmic_acpi_check=0on the kernel command line.
So I tried this:
$ cat /etc/modprobe.d/lenovot14s.conf options snd-rn-pci-acp3x dmic_acpi_check=0
And that did make it work indeed.
I have no idea what this means and why this makes it work.
The option basically should influence on the driver's behavior whether to probe the built-in d-mic or not, and it has no direct relationship with HDMI (supposedly via HD-audio bus), so it's puzzling how this fixes the problem.
Could you run alsa-info.sh (with --no-upload option) on both working and non-working cases, and attach both outputs for comparison?
I removed /etc/modprobe.d/lenovot14s.conf but now it still works ☹
I did a “sudo dnf --enablerepo=updates-testing update”
since I last rebooted, so it is possible that an update fixed this.
So unfortunately I cannot produce a “alsa-info.sh --no-upload” output for the non-working case anymore (I attached the output for the working case *without* /etc/modprobe.d/lenovot14s.conf (i.e. without snd_rn_pci_acp3x.dmic_acpi_check=0)
On Wed, 18 Jan 2023 18:05:23 +0100, Mike FABIAN wrote:
Takashi Iwai tiwai@suse.de さんはかきました:
On Wed, 18 Jan 2023 16:30:53 +0100, Mike FABIAN wrote:
With a Lenovo Thinkpad T14s (Gen1, Intel version), I tried to get sound on the monitor speakers via the HDMI cable.
It didn’t work out of the box and after a bit of googling I found:
https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T-series-Laptops/T14s-AMD-no-HDMI-audio-on-Linux/m-p/5081195?page=2which suggested to put
snd_rn_pci_acp3x.dmic_acpi_check=0on the kernel command line.
So I tried this:
$ cat /etc/modprobe.d/lenovot14s.conf options snd-rn-pci-acp3x dmic_acpi_check=0
And that did make it work indeed.
I have no idea what this means and why this makes it work.
The option basically should influence on the driver's behavior whether to probe the built-in d-mic or not, and it has no direct relationship with HDMI (supposedly via HD-audio bus), so it's puzzling how this fixes the problem.
Could you run alsa-info.sh (with --no-upload option) on both working and non-working cases, and attach both outputs for comparison?
I removed /etc/modprobe.d/lenovot14s.conf but now it still works ☹
I did a “sudo dnf --enablerepo=updates-testing update”
since I last rebooted, so it is possible that an update fixed this.
So unfortunately I cannot produce a “alsa-info.sh --no-upload” output for the non-working case anymore (I attached the output for the working case *without* /etc/modprobe.d/lenovot14s.conf (i.e. without snd_rn_pci_acp3x.dmic_acpi_check=0)
Hm, I see no snd-rn-pci-acp3x module is loaded there, so something might prevent it loaded (e.g. blacklist or such)?
And, with this state, can you use the built-in mic? Also, how after restoring the module option?
thanks,
Takashi
On Wed, 18 Jan 2023 19:45:16 +0100, Takashi Iwai wrote:
On Wed, 18 Jan 2023 18:05:23 +0100, Mike FABIAN wrote:
Takashi Iwai tiwai@suse.de さんはかきました:
On Wed, 18 Jan 2023 16:30:53 +0100, Mike FABIAN wrote:
With a Lenovo Thinkpad T14s (Gen1, Intel version), I tried to get sound on the monitor speakers via the HDMI cable.
It didn’t work out of the box and after a bit of googling I found:
https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T-series-Laptops/T14s-AMD-no-HDMI-audio-on-Linux/m-p/5081195?page=2which suggested to put
snd_rn_pci_acp3x.dmic_acpi_check=0on the kernel command line.
So I tried this:
$ cat /etc/modprobe.d/lenovot14s.conf options snd-rn-pci-acp3x dmic_acpi_check=0
And that did make it work indeed.
I have no idea what this means and why this makes it work.
The option basically should influence on the driver's behavior whether to probe the built-in d-mic or not, and it has no direct relationship with HDMI (supposedly via HD-audio bus), so it's puzzling how this fixes the problem.
Could you run alsa-info.sh (with --no-upload option) on both working and non-working cases, and attach both outputs for comparison?
I removed /etc/modprobe.d/lenovot14s.conf but now it still works ☹
I did a “sudo dnf --enablerepo=updates-testing update”
since I last rebooted, so it is possible that an update fixed this.
So unfortunately I cannot produce a “alsa-info.sh --no-upload” output for the non-working case anymore (I attached the output for the working case *without* /etc/modprobe.d/lenovot14s.conf (i.e. without snd_rn_pci_acp3x.dmic_acpi_check=0)
Hm, I see no snd-rn-pci-acp3x module is loaded there, so something might prevent it loaded (e.g. blacklist or such)?
And, with this state, can you use the built-in mic? Also, how after restoring the module option?
Also, maybe more fundamental question: how exactly "it didn't work"? Does the HDMI device appear on pipewire / PulseAudio, but the output results in silence? Or Is no HDMI listed there?
BTW, the lack of AMD SoC stuff might be related with the device power state. A cold boot might change the situation (or trying back to an older known kernel).
Takashi
Takashi Iwai tiwai@suse.de さんはかきました:
And, with this state, can you use the built-in mic? Also, how after restoring the module option?
Yes, I can use the microphone built into the laptop. I think I can use that always, independent on whether I use the module option or not.
Also, maybe more fundamental question: how exactly "it didn't work"? Does the HDMI device appear on pipewire / PulseAudio, but the output results in silence? Or Is no HDMI listed there?
HDMI is listed in pavucontrol.
Actually it is listed there 3 times:
HDMI/Displayport 3 Output (unplugged) HDMI/Displayport 2 Output (unplugged) HDMI/Displayport 1 Output (plugged in)
But when I select it, I heards nothing from the monitor speakers. I tried all 3 HDMI/Displayport in pavucontrol because I was not sure which one was the right one, but I didn’t hear anything when trying to use any of them.
xrandr showed me the following outputs:
$ xrandr | grep connected eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 174mm HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) DP-3 disconnected (normal left inverted right x axis y axis) DP-4 disconnected (normal left inverted right x axis y axis) DP-3-1 disconnected (normal left inverted right x axis y axis) DP-3-2 disconnected (normal left inverted right x axis y axis) DP-3-3 connected 3840x2160+1920+0 (normal left inverted right x axis y axis) 600mm x 340mm
DP-3-3 is my external monitor which has speakers.
After I did set that module option with modprobe and rebooted, I could select
HDMI/Displayport 1 Output (plugged in)
in pavucontrol and hear sound from the monitor speakers. So what xrandr calls DP-3-3 seems to be HDMI/Displayport 1 (plugged in) in pavucontrol.
BTW, the lack of AMD SoC stuff might be related with the device power state. A cold boot might change the situation (or trying back to an older known kernel).
I’ll try to boot again and see whether it breaks again. Currently I booted without the module option and it still works, but there was a kernel update.
On Fri, 20 Jan 2023 12:39:01 +0100, Mike FABIAN wrote:
Takashi Iwai tiwai@suse.de さんはかきました:
And, with this state, can you use the built-in mic? Also, how after restoring the module option?
Yes, I can use the microphone built into the laptop. I think I can use that always, independent on whether I use the module option or not.
Aha, then that's a different system from what I've thought. The mic is routed apparently via Intel SOF driver.
Also, maybe more fundamental question: how exactly "it didn't work"? Does the HDMI device appear on pipewire / PulseAudio, but the output results in silence? Or Is no HDMI listed there?
HDMI is listed in pavucontrol.
Actually it is listed there 3 times:
HDMI/Displayport 3 Output (unplugged) HDMI/Displayport 2 Output (unplugged) HDMI/Displayport 1 Output (plugged in)But when I select it, I heards nothing from the monitor speakers. I tried all 3 HDMI/Displayport in pavucontrol because I was not sure which one was the right one, but I didn’t hear anything when trying to use any of them.
xrandr showed me the following outputs:
$ xrandr | grep connected eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 174mm HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) DP-3 disconnected (normal left inverted right x axis y axis) DP-4 disconnected (normal left inverted right x axis y axis) DP-3-1 disconnected (normal left inverted right x axis y axis) DP-3-2 disconnected (normal left inverted right x axis y axis) DP-3-3 connected 3840x2160+1920+0 (normal left inverted right x axis y axis) 600mm x 340mmDP-3-3 is my external monitor which has speakers.
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.
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.
After I did set that module option with modprobe and rebooted, I could select
HDMI/Displayport 1 Output (plugged in)in pavucontrol and hear sound from the monitor speakers. So what xrandr calls DP-3-3 seems to be HDMI/Displayport 1 (plugged in) in pavucontrol.
BTW, the lack of AMD SoC stuff might be related with the device power state. A cold boot might change the situation (or trying back to an older known kernel).
I’ll try to boot again and see whether it breaks again. Currently I booted without the module option and it still works, but there was a kernel update.
That might explain. There were a few fixes about HDMI HD-audio stuff recently.
thanks,
Takashi
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.
On Sat, 11 Feb 2023 09:20:31 +0100, Mike FABIAN wrote:
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.
Thanks. Through a quick glance, there is no significant difference between both outputs.
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?
Yes, looks so.
$ 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
This is fine.
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.
Check the output of "aplay -L". It'll list the possible device arguments. If you still get an error, try like
% aplay -Dhw:0,3 -vv foo.wav
thanks,
Takashi
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?
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.
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 睡眠不足はいい仕事の敵だ。
participants (2)
-
Mike FABIAN -
Takashi Iwai