From nobody Tue Jul 28 10:03:45 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 4h8WJZ1MwYz6mVRB for ; Tue, 28 Jul 2026 10:03:58 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo63.interia.pl (smtpo63.interia.pl [217.74.67.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4h8WJY4N0Lz3gHy; Tue, 28 Jul 2026 10:03:57 +0000 (UTC) (envelope-from vermaden@interia.pl) Authentication-Results: mx1.freebsd.org; none Date: Tue, 28 Jul 2026 12:03:45 +0200 From: vermaden Subject: Re: Tragic State of FreeBSD Audio/Sound To: Tomoaki AOKI , Adrian Chadd Cc: Nuno Teixeira , Sulev-Madis Silber , "freebsd-current@freebsd.org" X-Mailer: interia.pl/pf09 In-Reply-To: <20260728181029.f4aeaf7a0bfbaf565f3468c6@dec.sakura.ne.jp> 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> <20260728181029.f4aeaf7a0bfbaf565f3468c6@dec.sakura.ne.jp> X-Originating-IP: 45.148.42.19 Message-Id: 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=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=dk; t=1785233030; bh=WsoAysCP3MVWYULIRwfvmAD4KD7BD4TM04e95Ien9J8=; h=Date:From:Subject:To:Message-Id:MIME-Version:Content-Type; b=he6d6aPLM33tC8qaUlBp4yO6MRsOb2U0HS/GjNZt2R7l4lgowSTJacZLiNdZUpM6Y E9WHvufhRZ3o3ApRRb/P4P27QwKr/WQoQsH0uHGC6k+Ev6WapO2xHZU9bxUbHE4h54 9n/ZkiZ3ixprtc5N5EdvG1l4v2zSHl/3H5CvqAIY= X-Rspamd-Queue-Id: 4h8WJY4N0Lz3gHy 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:16138, ipnet:217.74.64.0/22, country:PL] X-Spamd-Bar: ---- Hi. Temat: Re: Tragic State of FreeBSD Audio/Sound Data: 2026-07-28 11:12 Nadawca: "Tomoaki AOKI" <junchoon@dec.sakura.ne.jp> Adresat: "Adrian Chadd" <adrian@freebsd.org>; DW: "Nuno Teixeira" <eduardo@freebsd.org>; "Sulev-Madis Silber" <freebsd-current-freebsd-org111@ketas.si.pri.ee>; freebsd-current@freebsd.org; > > > 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 My ideas to 'stress' system to make it happen - fire up all of these at once: # glmark2 # unixbench # sysbench cpu --threads=$( nproc ) run # blogbench # stress-ng # make buildworld Should help ... Regards, vermaden