[arch-general] sound problem with chromium
hi, I have an ArchLinux installed on a usb disk (eg. "mobile"). ~ # uname -r 5.15.37-1-lts ~ # pacman -Q | egrep 'alsa|chromium|firefox|mplayer' alsa-lib 1.2.6.1-1 alsa-topology-conf 1.2.5.1-1 alsa-ucm-conf 1.2.6.3-1 alsa-utils 1.2.6-1 chromium 101.0.4951.54-1 firefox 100.0-1 mplayer 38359-1 when it runs on my Dell Latitude E5250, Chromium works without any difficulty to play a YouTube video for example : the sound is ok (same for Firefox or Mplayer). on the other hand, when it runs on my Lenovo ThinkPad X1 Carbon, Chromium has problems with the sound (which is not the case for Firefox or Mplayer which both produce sound). it happens from time to time in this (hardware) environment that Chromium produces sound and the next moment (simple stop/restart of the browser) it fails (without anything being done in between) ! another surprising thing is that if I access a video (zunRcH4nUPI) this way "chromium https://www.youtube.com/" (and then click on the desired video) I often don't get any sound while if I access it this way "chromium https://www.youtube.com/watch?v=zunRcH4nUPI" the sound works ! I spent a lot of time trying to understand the problem and looking for a solution/track on the internet but, having found nothing, I throw a bottle in the water... regards, lacsaP.
on the other hand, when it runs on my Lenovo ThinkPad X1 Carbon, Chromium has problems with the sound
Check the Arch wiki for the requirements of the exact model and generation of X1. a wild guess would be, you need to install `sof-firmware` but it's hard to say without more data -- damjan
I just had a look in the wiki and did not see anything special. sof-firmware is installed. ~ # pacman -Q | grep 'sof' sof-firmware 2.1.1-1 the problem seems to be between chromium and my lenovo. I will test on other machines soon... Le jeu. 5 mai 2022 à 12:36, Damjan Georgievski via arch-general < arch-general@lists.archlinux.org> a écrit :
on the other hand, when it runs on my Lenovo ThinkPad X1 Carbon, Chromium has problems with the sound
Check the Arch wiki for the requirements of the exact model and generation of X1.
a wild guess would be, you need to install `sof-firmware` but it's hard to say without more data
-- damjan
Pascal via arch-general <arch-general@lists.archlinux.org> wrote:
hi,
I have an ArchLinux installed on a usb disk (eg. "mobile").
~ # uname -r 5.15.37-1-lts ~ # pacman -Q | egrep 'alsa|chromium|firefox|mplayer' alsa-lib 1.2.6.1-1 alsa-topology-conf 1.2.5.1-1 alsa-ucm-conf 1.2.6.3-1 alsa-utils 1.2.6-1 chromium 101.0.4951.54-1 firefox 100.0-1 mplayer 38359-1
when it runs on my Dell Latitude E5250, Chromium works without any difficulty to play a YouTube video for example : the sound is ok (same for Firefox or Mplayer).
on the other hand, when it runs on my Lenovo ThinkPad X1 Carbon, Chromium has problems with the sound (which is not the case for Firefox or Mplayer which both produce sound). it happens from time to time in this (hardware) environment that Chromium produces sound and the next moment (simple stop/restart of the browser) it fails (without anything being done in between) ! another surprising thing is that if I access a video (zunRcH4nUPI) this way "chromium https://www.youtube.com/" (and then click on the desired video) I often don't get any sound while if I access it this way "chromium https://www.youtube.com/watch?v=zunRcH4nUPI" the sound works !
I spent a lot of time trying to understand the problem and looking for a solution/track on the internet but, having found nothing, I throw a bottle in the water...
regards, lacsaP.
Can you try cutting down the environment by running chromium within a dedicated X server? That is, run a 2nd, or just one, Xserver, dedicated to chromium. Desirbly, without a desktop environment, and without a window manager either. Just chromium, nothing else. I find chromium very problematic, avoiding it as much as I can. Never the less, I do have to use it from time to time. And I do think diversity is a must have. -- u34
I just did a little test like this: # user add -m test # passwd test # echo "chromium https://youtube.com" > /home/test/.xinitrc logoff and then logon (slim) as test. a first test "bingo", it works, there is sound ! I extend the test : I close Chromium, I reconnect again immediatly and KO, no sound. I try again : close the browser and reopen the session as test user but still KO. Le jeu. 5 mai 2022 à 13:48, u34--- via arch-general < arch-general@lists.archlinux.org> a écrit :
Pascal via arch-general <arch-general@lists.archlinux.org> wrote:
hi,
I have an ArchLinux installed on a usb disk (eg. "mobile").
~ # uname -r 5.15.37-1-lts ~ # pacman -Q | egrep 'alsa|chromium|firefox|mplayer' alsa-lib 1.2.6.1-1 alsa-topology-conf 1.2.5.1-1 alsa-ucm-conf 1.2.6.3-1 alsa-utils 1.2.6-1 chromium 101.0.4951.54-1 firefox 100.0-1 mplayer 38359-1
when it runs on my Dell Latitude E5250, Chromium works without any difficulty to play a YouTube video for example : the sound is ok (same for Firefox or Mplayer).
on the other hand, when it runs on my Lenovo ThinkPad X1 Carbon, Chromium has problems with the sound (which is not the case for Firefox or Mplayer which both produce sound). it happens from time to time in this (hardware) environment that Chromium produces sound and the next moment (simple stop/restart of the browser) it fails (without anything being done in between) ! another surprising thing is that if I access a video (zunRcH4nUPI) this way "chromium https://www.youtube.com/" (and then click on the desired video) I often don't get any sound while if I access it this way "chromium https://www.youtube.com/watch?v=zunRcH4nUPI" the sound works !
I spent a lot of time trying to understand the problem and looking for a solution/track on the internet but, having found nothing, I throw a bottle in the water...
regards, lacsaP.
Can you try cutting down the environment by running chromium within a dedicated X server? That is, run a 2nd, or just one, Xserver, dedicated to chromium. Desirbly, without a desktop environment, and without a window manager either. Just chromium, nothing else.
I find chromium very problematic, avoiding it as much as I can. Never the less, I do have to use it from time to time. And I do think diversity is a must have.
-- u34
Are you using Alsa directly, no pulseaudio or pipewire? Something could be wonky with your dmix config and it's getting disabled, thus only a single application can have access to the sound playback at once.
Alsa directly : no PA or PW. when i run Chromium from a terminal, i get these two error messages about Alsa but they also appear when the sound is working : [4765:4765:0504/164956.649650:ERROR:alsa_util.cc(204)] PcmOpen: default,Device or resource busy [4765:4765:0504/164956.649811:ERROR:alsa_util.cc(204)] PcmOpen: plug:default,Device or resource busy Le jeu. 5 mai 2022 à 15:46, Jesse Jaara via arch-general < arch-general@lists.archlinux.org> a écrit :
Are you using Alsa directly, no pulseaudio or pipewire? Something could be wonky with your dmix config and it's getting disabled, thus only a single application can have access to the sound playback at once.
I checked in my session the concurrent accesses with fuser -v /dev/snd/* and killed the only one that was present and could interfere (volumeicon *that was also present with Firefox and Mplayer*). Le jeu. 5 mai 2022 à 15:50, Pascal <patatetom@gmail.com> a écrit :
Alsa directly : no PA or PW.
when i run Chromium from a terminal, i get these two error messages about Alsa but they also appear when the sound is working : [4765:4765:0504/164956.649650:ERROR:alsa_util.cc(204)] PcmOpen: default,Device or resource busy [4765:4765:0504/164956.649811:ERROR:alsa_util.cc(204)] PcmOpen: plug:default,Device or resource busy
Le jeu. 5 mai 2022 à 15:46, Jesse Jaara via arch-general < arch-general@lists.archlinux.org> a écrit :
Are you using Alsa directly, no pulseaudio or pipewire? Something could be wonky with your dmix config and it's getting disabled, thus only a single application can have access to the sound playback at once.
Do you perhaps have any /etc/asound.conf or .asoundrc or similarly named files messing up your sound config? Additionally (another wild guess), try running aplay -l -L and report the output. On Thu, May 5, 2022, 16:00 Pascal via arch-general < arch-general@lists.archlinux.org> wrote:
I checked in my session the concurrent accesses with fuser -v /dev/snd/* and killed the only one that was present and could interfere (volumeicon *that was also present with Firefox and Mplayer*).
Le jeu. 5 mai 2022 à 15:50, Pascal <patatetom@gmail.com> a écrit :
Alsa directly : no PA or PW.
when i run Chromium from a terminal, i get these two error messages about Alsa but they also appear when the sound is working : [4765:4765:0504/164956.649650:ERROR:alsa_util.cc(204)] PcmOpen: default,Device or resource busy [4765:4765:0504/164956.649811:ERROR:alsa_util.cc(204)] PcmOpen: plug:default,Device or resource busy
Le jeu. 5 mai 2022 à 15:46, Jesse Jaara via arch-general < arch-general@lists.archlinux.org> a écrit :
Are you using Alsa directly, no pulseaudio or pipewire? Something could be wonky with your dmix config and it's getting disabled, thus only a single application can have access to the sound playback at once.
hi, neither one nor the other. here is the return of the `aplay -l -L` command on my lenovo : null Discard all samples (playback) or generate zero samples (capture) default:CARD=sofhdadsp sof-hda-dsp, Default Audio Device sysdefault:CARD=sofhdadsp sof-hda-dsp, Default Audio Device **** Liste des périphériques matériels PLAYBACK **** carte 0 : sofhdadsp [sof-hda-dsp], périphérique 0 : HDA Analog (*) [] Sous-périphériques : 1/1 Sous-périphérique #0 : subdevice #0 carte 0 : sofhdadsp [sof-hda-dsp], périphérique 1 : HDA Digital (*) [] Sous-périphériques : 1/1 Sous-périphérique #0 : subdevice #0 carte 0 : sofhdadsp [sof-hda-dsp], périphérique 3 : HDMI1 (*) [] Sous-périphériques : 1/1 Sous-périphérique #0 : subdevice #0 carte 0 : sofhdadsp [sof-hda-dsp], périphérique 4 : HDMI2 (*) [] Sous-périphériques : 1/1 Sous-périphérique #0 : subdevice #0 carte 0 : sofhdadsp [sof-hda-dsp], périphérique 5 : HDMI3 (*) [] Sous-périphériques : 1/1 Sous-périphérique #0 : subdevice #0 snd_hda_intel is loaded with `options snd_hda_intel enable=0,1` to disable HDMI output. regards. Le ven. 6 mai 2022 à 03:14, Neven Sajko <nsajko@gmail.com> a écrit :
Do you perhaps have any /etc/asound.conf or .asoundrc or similarly named files messing up your sound config?
Additionally (another wild guess), try running aplay -l -L and report the output.
On Thu, May 5, 2022, 16:00 Pascal via arch-general < arch-general@lists.archlinux.org> wrote:
I checked in my session the concurrent accesses with fuser -v /dev/snd/* and killed the only one that was present and could interfere (volumeicon *that was also present with Firefox and Mplayer*).
Le jeu. 5 mai 2022 à 15:50, Pascal <patatetom@gmail.com> a écrit :
Alsa directly : no PA or PW.
when i run Chromium from a terminal, i get these two error messages about Alsa but they also appear when the sound is working : [4765:4765:0504/164956.649650:ERROR:alsa_util.cc(204)] PcmOpen: default,Device or resource busy [4765:4765:0504/164956.649811:ERROR:alsa_util.cc(204)] PcmOpen: plug:default,Device or resource busy
Le jeu. 5 mai 2022 à 15:46, Jesse Jaara via arch-general < arch-general@lists.archlinux.org> a écrit :
Are you using Alsa directly, no pulseaudio or pipewire? Something could be wonky with your dmix config and it's getting disabled, thus only a single application can have access to the sound playback at once.
Try loading snd_hda_intel without extra options. If this helps, you can always use the ALSA_CARD environment variable for choosing the audio device.
with or without the option, Chromium is still willing to play sound once in a while. what really bothers me is the randomness of the problem. some additional information : $ journalctl -b | grep -i _hda_ May 09 08:39:09 archlive kernel: snd_hda_intel: probe of 0000:00:1f.3 failed with error -2 May 09 08:39:12 archlive kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC285: line_outs=2 (0x14/0x17/0x0/0x0/0x0) type:speaker May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: mono: mono_out=0x0 May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: inputs: May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: Mic=0x19 May 09 08:39:13 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten May 09 08:39:13 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi3 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi2 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi1 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Codec Output Pin1 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Codec Input Pin1 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Analog Codec Playback overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Digital Codec Playback overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Alt Analog Codec Playback overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Analog Codec Capture overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Digital Codec Capture overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Alt Analog Codec Capture overwritten May 09 08:39:13 archlive kernel: input: sof-hda-dsp Mic as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input13 May 09 08:39:13 archlive kernel: input: sof-hda-dsp Headphone as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input14 May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input15 May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=4 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input16 May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17 May 09 14:30:25 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: didn't find PCM for DAI Digital Codec DAI May 09 14:30:25 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC: error at snd_soc_dai_startup on Digital Codec DAI: -22 regards, lacsaP. Le lun. 9 mai 2022 à 14:32, Neven Sajko <nsajko@gmail.com> a écrit :
Try loading snd_hda_intel without extra options. If this helps, you can always use the ALSA_CARD environment variable for choosing the audio device.
hi, the problem seems to have disappeared after installation of pulseaudio-alsa which appears to be essential to the proper functioning of Chromium. when Chromium had "the hand" on the audio and was able to produce sound, I could not hear the other participants talking with Jitsi while I could hear their arrival (sound signal) and the sound test was ok (this was also the case with Jitsi under Firefox). to summarize, pulseaudio-alsa seems to have corrected the random sound problem with Chromium and the second problem that appeared in the meantime with Jitsi. if this is the case, it could be added as a Chromium/Firefox dependency (eg. pacman)... regards, lacsaP. Le lun. 9 mai 2022 à 14:56, Pascal <patatetom@gmail.com> a écrit :
with or without the option, Chromium is still willing to play sound once in a while. what really bothers me is the randomness of the problem.
some additional information : $ journalctl -b | grep -i _hda_ May 09 08:39:09 archlive kernel: snd_hda_intel: probe of 0000:00:1f.3 failed with error -2 May 09 08:39:12 archlive kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC285: line_outs=2 (0x14/0x17/0x0/0x0/0x0) type:speaker May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: mono: mono_out=0x0 May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: inputs: May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: Mic=0x19 May 09 08:39:13 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten May 09 08:39:13 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi3 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi2 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi1 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Codec Output Pin1 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Codec Input Pin1 overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Analog Codec Playback overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Digital Codec Playback overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Alt Analog Codec Playback overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Analog Codec Capture overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Digital Codec Capture overwritten May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Alt Analog Codec Capture overwritten May 09 08:39:13 archlive kernel: input: sof-hda-dsp Mic as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input13 May 09 08:39:13 archlive kernel: input: sof-hda-dsp Headphone as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input14 May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input15 May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=4 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input16 May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17 May 09 14:30:25 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: didn't find PCM for DAI Digital Codec DAI May 09 14:30:25 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC: error at snd_soc_dai_startup on Digital Codec DAI: -22
regards, lacsaP.
Le lun. 9 mai 2022 à 14:32, Neven Sajko <nsajko@gmail.com> a écrit :
Try loading snd_hda_intel without extra options. If this helps, you can always use the ALSA_CARD environment variable for choosing the audio device.
participants (5)
-
Damjan Georgievski
-
Jesse Jaara
-
Neven Sajko
-
Pascal
-
u34＠net9.ga