Alexandre Ratchov wrote: > 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
Thank you so much for the explanation!
