On Fri, Dec 09, 2022 at 01:41:55PM +0300, Aleksandr Mikhaylov wrote:
> Hello all!
> 
> I'm using OpenBSD 7.2 RELEASE, 
> but I've seen this problem on earlier versions as well. 
> Please tell me, when I am playing audio through sndio,
> for example with firefox or mpd, 
> and the processor load starts to increase,
> for example because I opened a heavy web page or some heavy application,
> sometimes I hear clicks, or my audio is interrupted,
> and I have to restart the playback.
> I can see in the mpd log at this time:
> 
> output: Failed to play on "Libao Audio Device" (sndio): sndio write failed
> 
> I tried increasing the sndiod buffer to 9600,
> but that didn't do anything.
> I also tried running sndio with the -d flag,
> but I didn't see any errors. 
> I have two laptops with OpenBSD, a Thinkpad x250 and a Latitude 5300,
> and both laptops have this problem.
> If anyone can tell me what might be the problem,
> I would be very grateful, thank you very much.

I've noticed similar problems and many have reported them. The OpenBSD
kernel is not preemptive, so while big programs (including browsers)
are running long kernel code-paths, audio doesn't get the CPU timely
and audio drops.

AFAICS, the kernel is improving a lot with time, but browsers (and
sites they are running) are becoming heavier, compilers are becoming
heavier, etc.

Interestingly (at least to my ears and for my workload) the annoyances
caused by big programs don't depend much on the audio deadline (at
least in the 10-100ms range). This suggests that there are only huge
non-preemptive kernel code-paths. Userland is affected, USB audio
devices (operated at IPL_SOFTNET) are affected, but PCI devices
(operated at IPL_AUDIO) are not affected; this might indicate that the
blocking code paths run at above IPL_SOFTNET and below IPL_AUDIO. My 2
cents, in case this rings a bell to someone.

Meanwhile, I suggest you to try to reduce the processes/services that
you dont need but load the kernel. In my experiences processes that
allocate/free big amounts of memory always cause underruns.

HTH

Reply via email to