Chromium audio popping, fix it by changing the sndiod rate to 44100

I had terrible audio popping with Chromium which use sndiod audio

The fix is to change the sndiod sample rate to 44100 from the default 44800

as mentioned in this post by patovm04


Code:
sudo sysrc sndiod_enable="YES"
sudo sysrc sndiod_flags="-r 44100"

or manually edit the config file

Code:
sudo vi /etc/rc.conf

and add the following code

Code:
sndiod_enable="YES"
sndiod_flags="-r 44100"

reboot for good measure

open Chromium play a video and you should have no more audio popping
cheers to patovm04 for the fix, this has been something thats been annoying me for a long time
 
I had terrible audio popping with Chromium which use sndiod audio

The fix is to change the sndiod sample rate to 44100 from the default 44800

...

open Chromium play a video and you should have no more audio popping
cheers to patovm04 for the fix, this has been something thats been annoying me for a long time

That's strange because most web videos are 48kHz, which means you add a sample rate conversion to your audio stack (probably in sndiod). If that helps it's maybe just the additional buffer for the conversion.

Out of interest, could you provide the output of sysctl hw.snd.verbose=2; cat /dev/sndstat when playing the video?
 
That's strange because most web videos are 48kHz, which means you add a sample rate conversion to your audio stack (probably in sndiod). If that helps it's maybe just the additional buffer for the conversion.

Out of interest, could you provide the output of sysctl hw.snd.verbose=2; cat /dev/sndstat when playing the video?
thats what i thought

changing the sample rate does remove the load pops
but i can still hear what id call micro audio stuttering and popping

like an old vinyl record

i commented out sndiod_flags="-r 44100" in rc.conf and rebooted

will run

Code:
sysctl hw.snd.verbose=2; cat /dev/sndstat
 
Code:
doas sysctl hw.snd.verbose=2
cat /dev/sndstat

ouput of /dev/sndstat while playing a video

my audio device is

Code:
pcm1: <Realtek ALC298 (Left Analog Headphones)> on hdaa0 (1p:1v/0r:0v) default

Code:
FreeBSD Audio Driver (64bit 2009061500/amd64)
Installed devices:
pcm0: <Realtek ALC298 (Internal Analog)> on hdaa0 (1p:1v/1r:1v)
    snddev flags=0x2e2<AUTOVCHAN,BUSY,MPSAFE,REGISTERED,VPC>
    [pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000004
    interrupts 0, underruns 0, feed 0, ready 0 [b:2048/1024/2|bs:2048/1024/2]
    channel flags=0x2100<BUSY,HAS_VCHAN>
    {userland} -> feeder_mixer(0x00200010) -> {hardware}
    pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000
    interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:0/0/0]
    channel flags=0x10000000<VIRTUAL>
    {userland} -> feeder_root(0x00000000) -> {hardware}
    [pcm0:record:dsp0.r0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000005
    interrupts 0, overruns 0, feed 0, hfree 512, sfree 512 [b:512/256/2|bs:512/256/2]
    channel flags=0x2100<BUSY,HAS_VCHAN>
    {hardware} -> feeder_root(0x00200010) -> feeder_mixer(0x00200010) -> {userland}
    pcm0:record:dsp0.r0[pcm0:virtual:dsp0.vr0]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000
    interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0]
    channel flags=0x10000000<VIRTUAL>
    {hardware} -> feeder_root(0x00000000) -> {userland}
pcm1: <Realtek ALC298 (Left Analog Headphones)> on hdaa0 (1p:1v/0r:0v) default
    snddev flags=0x200002e3<SIMPLEX,AUTOVCHAN,BUSY,MPSAFE,REGISTERED,VPC,PRIO_WR>
    [pcm1:play:dsp1.p0]: spd 48000, fmt 0x00200010, flags 0x00002108, 0x00000004
    interrupts 2006, underruns 0, feed 2006, ready 0 [b:2048/1024/2|bs:2048/1024/2]
    channel flags=0x2108<TRIGGERED,BUSY,HAS_VCHAN>
    {userland} -> feeder_mixer(0x00200010) -> {hardware}
    pcm1:play:dsp1.p0[pcm1:virtual:dsp1.vp0]: spd 48000, fmt 0x00200010, flags 0x1000114c, 0x00000021, pid 70770 (sndiod)
    interrupts 0, underruns 0, feed 2006, ready 15616 [b:0/0/0|bs:16384/1024/16]
    channel flags=0x1000114c<RUNNING,TRIGGERED,NBIO,BUSY,HAS_SIZE,VIRTUAL>
    {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> {hardware}
pcm2: <Intel Kaby Lake (HDMI/DP 8ch)> on hdaa1 (1p:1v/0r:0v)
    snddev flags=0x2e7<SIMPLEX,AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC>
    [pcm2:play:dsp2.p0]: spd 48000, fmt 0x00200010, flags 0x00006100, 0x00000004
    interrupts 0, underruns 0, feed 0, ready 0 [b:2048/1024/2|bs:2048/1024/2]
    channel flags=0x6100<BUSY,HAS_VCHAN,VCHAN_PASSTHROUGH>
    {userland} -> feeder_mixer(0x00200010) -> {hardware}
    pcm2:play:dsp2.p0[pcm2:virtual:dsp2.vp0]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000
    interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:0/0/0]
    channel flags=0x10000000<VIRTUAL>
    {userland} -> feeder_root(0x00000000) -> {hardware}
No devices installed from userspace.
 
Nothing suspicious in sndstat, that's as straight as it could get from a pcm device perspective. Also there's like 90ms of buffer which is plenty for almost any case, and there's no recording involved.


These stories always sound like snake oil to me, but they're going by the trajectory of scheduler interference. If you want to experiment you could give sndiod realtime priority with rtprio() and / or try to disable hardware acceleration (GPU).

Anecdotally I had to get rid of all nvidia cards in my boxes to get reliable latency in jack. Process scheduling was really messed up. That was the 340.x driver back then, hope it's fixed by now.
 
i did see someone mentioning sndiod realtime priority with rtprio

in my /etc/rc.conf in my kld_list i have mac_priority

searching for " sndiod realtime priority with rtprio" lists the reddit post in the search results
google is getting worse for finding things

is there a flag to set sndiod realtime in the rc.conf

ill havent found search results yet
will keep looking
 
Anecdotally I had to get rid of all nvidia cards in my boxes to get reliable latency in jack. Process scheduling was really messed up. That was the 340.x driver back then, hope it's fixed by now.

The professional audio community measured NVidia as worse than ATI/AMD graphics influence on audio latency, but that seems to have been fixed on Windows for quite some time now.
 
i have an nvidia card but only have issues with chromium and audio popping

i had a quick scan through the sndiod man page but didnt see anything about realtime

would sndiod realtime be enabled with sndiod_flags in /etc/rc.conf
havent been able to find anything in my searches yet
 
i had a quick scan through the sndiod man page but didnt see anything about realtime

would sndiod realtime be enabled with sndiod_flags in /etc/rc.conf
havent been able to find anything in my searches yet

AFAIK sndiod has no in-built realtime priority facility, but for a test you can apply it manually with rtprio() (as root for simplicity). When running, find the pid with ps | grep sndiod and then give it realtime priority: rtprio 10 {pid}. top() should show a special priority value then.

The mac_priority() module is needed for non-root users to gain realtime privilege, add the specific users to the realtime group for that.

The professional audio community measured NVidia as worse than ATI/AMD graphics influence on audio latency, but that seems to have been fixed on Windows for quite some time now.

I just noticed really long delays until Jack was scheduled again, interestingly also with lots of CPU cores available. Don't have a current nvidia card, so can't measure now.
 
seems like a bit of pain to have to do every time you want to use chromium
and not a fix that would be suitable for new user users

The rtprio hack would be a one time experiment to test the scheduling hypothesis, not meant as a permanent solution. You could also try to increase the sndiod() buffer size with the -b flag, although the default of 7680 frames (160ms @ 48kHz) seems already quite high.

ill have a play around with using the chromium flags
see if i can find anything that could be added to a desktop entry


From a recent chromium commit, PR 246449:
with these changes, chromium now automatically selects which
audio backend to use in the following order:

pulse (if running) -> sndio -> alsa -> fake

an additional command line option has been also implemented so
that the user can force which backend to use:

--audio-backend={auto,sndio,pulse,alsa}
 
i just tried using the --audio-backend option with pulse audio
and it does work but you have to start pulse audio first

start pulse audio

Code:
pulseaudio --start --daemonize 2>/dev/null

use --audio-backend with pulse audio

Code:
--audio-backend=pulse

desktop entry

Code:
~/.local/share/applications/chromium-browser.desktop

Code:
[Desktop Entry]
Type=Application
Version=1.0
Encoding=UTF-8
Name=Chromium
Comment=Google web browser based on WebKit
Icon=chrome
Exec=chrome --audio-backend=pulse %U
Categories=Application;Network;WebBrowser;
MimeType=text/html;text/xml;application/xhtml+xml;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;
StartupNotify=true

kill pulse audio and the audio will stop in chromium

Code:
pulseaudio -k

launching chromium with the --audio-backend=pulse option doesnt start the pulse audio daemon
you have to manually with

Code:
pulseaudio --start --daemonize 2>/dev/null

im on Freebsd 14.1 quarterly branch
 
Aaaand ... the chromium audio backend command line switches are gone:

www/chromium: update to 127.0.6533.88

This update also removes the --audio-backend command line switch
in favor of an actual setting in the browser that can be changed
at chrome://flags/#audio-backend
 
Also I played around with sndiod and chromium, because I had short audio gaps every few seconds. Both running sndiod with realtime priority and increasing the buffer size did help with that - same as introducing a sample rate conversion as proposed in the original post.
Definitely something that could be improved with sndiod.
 
Back
Top