Date: Mon, 27 Jul 2026 10:17:46 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Cc: Sulev-Madis Silber <freebsd-current-freebsd-org111@ketas.si.pri.ee>, freebsd-current@freebsd.org Subject: Re: Tragic State of FreeBSD Audio/Sound Message-ID: <CAJ-VmomrsF0TDC7LDP1khyXgMREc98ysmn75NwL8Qm0C7qKnGQ@mail.gmail.com> In-Reply-To: <20260727190324.4b14bd9d7581c02c1cb001db@dec.sakura.ne.jp> References: <hkttyyfmuguexmliuhmg@ewtn> <sirudbjwrqwlhpzjpfqf@abqv> <CAK7dMtCRpXO71v=AEsrtuQufVJHjN%2B%2BhsN6CT_MkXhMa1-JOzw@mail.gmail.com> <CALH631mZWS9e9FDXPUT8N8W8WnNnpfYaoPuRyqXhqNTW9=atLw@mail.gmail.com> <CAK7dMtC0f7SgU7k6Yvbqg94eksd5UJ1meX7o2_0ukAteZPb-9g@mail.gmail.com> <20260722085416.407316d393dce1884c29a3c7@dec.sakura.ne.jp> <CAK7dMtBDQTwFkQ2UKgz1LtniZBdaWBnfL4iwUo1kFT5d34xSdQ@mail.gmail.com> <20260724001549.c947af418add25dd00ac0344@dec.sakura.ne.jp> <CAK7dMtBO4C5H9uexDfLjzL-ovuXMU8s-t5D-rTDxJcfNq%2BAMmg@mail.gmail.com> <20260724193239.d2eb613e0c4f42b90925eb46@dec.sakura.ne.jp> <20260726090359.4082568fe922add2dc01deb2@dec.sakura.ne.jp> <CAJ-VmonRmyrhpmAFkf7dAg2VdVFQKjeYtWMBYPSBvohuGBg-9w@mail.gmail.com> <wizxwdgtrmwqlrhgojon@qeft> <0AC6B63B-2A37-4F8D-BDBD-36D09F584913@ketas.si.pri.ee> <20260727190324.4b14bd9d7581c02c1cb001db@dec.sakura.ne.jp>
index | next in thread | previous in thread | raw e-mail
On Mon, 27 Jul 2026 at 03:04, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> 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. -adrianhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomrsF0TDC7LDP1khyXgMREc98ysmn75NwL8Qm0C7qKnGQ>