From nobody Tue Jul 28 09:10:29 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4h8V755rxmz6mPp6 for ; Tue, 28 Jul 2026 09:10:41 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4h8V7461khz3QSQ; Tue, 28 Jul 2026 09:10:39 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from delta.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 66S9ATSN095286; Tue, 28 Jul 2026 18:10:30 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1785229836; bh=e5G7gj4S9xKQgG+9yXJNQ+alYoPMGG189KD+h+N1Mbs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=gtWKEURT2v6D8yUEQsiyf53PuQdFg9mU4cXqzhJdMY2kXLNCoStSEwDgF+y7ypoge qgVbRF2X25INEEjHGKN8/APrfLzvh2umF10H5zH5MP+Zlqo8vxS6SFy7hNzNGa6+2k V1gCPeZ8cbjI5MXMFPedOyV/NbKMpNuHIMBeFqII= Date: Tue, 28 Jul 2026 18:10:29 +0900 From: Tomoaki AOKI To: Adrian Chadd Cc: Nuno Teixeira , Sulev-Madis Silber , freebsd-current@freebsd.org Subject: Re: Tragic State of FreeBSD Audio/Sound Message-Id: <20260728181029.f4aeaf7a0bfbaf565f3468c6@dec.sakura.ne.jp> In-Reply-To: References: <20260722085416.407316d393dce1884c29a3c7@dec.sakura.ne.jp> <20260724001549.c947af418add25dd00ac0344@dec.sakura.ne.jp> <20260724193239.d2eb613e0c4f42b90925eb46@dec.sakura.ne.jp> <20260726090359.4082568fe922add2dc01deb2@dec.sakura.ne.jp> <0AC6B63B-2A37-4F8D-BDBD-36D09F584913@ketas.si.pri.ee> <20260727190324.4b14bd9d7581c02c1cb001db@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4h8V7461khz3QSQ X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Spamd-Bar: ---- On Mon, 27 Jul 2026 20:24:09 -0700 Adrian Chadd wrote: > On Mon, 27 Jul 2026 at 15:09, Nuno Teixeira wrote: > > > > > >> 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.) > >> > >> > >> > >> 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 > >> > > > > Hello, > > > > I usually linten to youtube when doing poudriere builds. Music helps the process and poudriere build better. > > > > I use an usb dac with: > > > > hw.snd.latency=10 > > hw.usb.uaudio.buffer_ms=8 > > > > IMHO it helps a little. > > neat. again, if you can reproduce this then please file a bug, include > information about your hardware > and what you're doing on it to elicit the terrible behviour. > > > > > -adrian In my case, the issue rarely (about once per several months, including "stop playing" cases) happens, thus, hard to reproduce. Possibly (too wild guess, though) race conditions between *I/O pressures by heavy poudriere builds *timing to send payload to USB audio *timing to send/receive I/O from/to USB peripherals *reading audiofile (in my case, mostly FLAC) *processing audio data to send to USB audio In some cases, buzz sounds. In some other cases, sound stops, but audacious thinks it's sanely playing (slider moves, spectrum moves). I think the "sound stops" case would be PCM payload to USB audio is clamped to zero, instead of random value for buzz cases. Creating reproducer may be... too hard for me. Regards. -- Tomoaki AOKI