On Mon, 27 Jul 2026 at 03:04, Tomoaki AOKI <[email protected]> wrote: > > Another datapoint. > > When I've experienced "buzz" was when playing flac audio > using audacious AND under quite heavy loads (maybe especially > high I/O loads on staging / packaging) by poudriere builds > and `make buildworld` in case base llvm is under rebuilding. > > Experienced both on pulseaudio and OSS backends, and today > just experienced on pipewire backend, too. > > If this is caused by convergences on buses, I think > glmark2 (or any other GPU-intensive benchmarks for the computer) > could eat up bus bandwidth and causing the issue. > > Just my 2 JPY. ;-) >
If you're experiencing "buzz" like I think you are then it's the same frame being queued over and over again to the DAC. Typically I've only seen that happen here when I have the kernel panic (we're not stopping audio DMA at this point, and I don't know why it's looping over.) If it's happening without a panic then it could be worthwhile digging into whether there's some driver bug around DMA and interrupt handling latency in high load scenarios. I'm unsurprised /i/ have not reproduced it as I don't do crazy stuff like run poudriere locally whilst also watching youtube. If you're interested in reproducing and chasing down /this/ but then I think this would be a fine thing to reproduce it locally on a given machine, file a bug, and then we can dig into profiling what's going on. eg if we can reproduce it with something VERY STUPID - eg mpg123 playing an mp3 direct to /dev/dsp* with no other virtual audio stack running - we can then focus on the kernel side to see if there's weird driver issues under high IO/interrupt load. Even in the year of our lord "LLMs are available" there's only so much one can do in long email threads; at some point bugs need reproducing, PRs need filing and developer / user time needs to happen. Let's be methodical about it to help out the sound folks in figuring it out. -adrian
