From nobody Mon Dec 25 14:18:13 2023 X-Original-To: freebsd-multimedia@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 4SzKkf0MjWz54mVN for ; Mon, 25 Dec 2023 14:18:18 +0000 (UTC) (envelope-from dev@submerge.ch) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SzKkc0W4Lz3LWG; Mon, 25 Dec 2023 14:18:16 +0000 (UTC) (envelope-from dev@submerge.ch) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of dev@submerge.ch designates 2001:8e0:40:325::36 as permitted sender) smtp.mailfrom=dev@submerge.ch; dmarc=none Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CF14634052B; Mon, 25 Dec 2023 15:18:13 +0100 (CET) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/28147.7981); Mon, 25 Dec 2023 15:18:13 +0100 (CET) Received: from interway.li (sendai-nord.iway.ch [212.25.24.38]) by gozo.iway.ch (Postfix) with ESMTP; Mon, 25 Dec 2023 15:18:13 +0100 (CET) Received: from [145.40.196.39] (account fw@submerge.ch HELO z800.localnet) by sendai-nord.interway.li (CommuniGate Pro SMTP 7.1.0) with ESMTPSA id 254377107; Mon, 25 Dec 2023 15:18:13 +0100 From: Florian Walpen To: freebsd-multimedia@freebsd.org, Christos Margiolis Cc: Joseph Mingrone , Florian Walpen Subject: Re: RFC - Work on FreeBSD's Audio Stack Date: Mon, 25 Dec 2023 15:18:13 +0100 Message-ID: <4087619.O2WMGSuNBG@z800> In-Reply-To: <7097536.Jf4ITVjuem@z800> References: <86ttomxg11.fsf@phe.ftfl.ca> <7097536.Jf4ITVjuem@z800> List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spamd-Result: default: False [-2.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.99)[-0.988]; MID_RHS_NOT_FQDN(0.50)[]; CTE_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:8e0::/32:c]; RCVD_IN_DNSWL_LOW(-0.20)[212.25.24.38:received,2001:8e0:40:325::36:from]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:8758, ipnet:2001:8e0::/32, country:CH]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[submerge.ch]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4SzKkc0W4Lz3LWG X-Spamd-Bar: -- On Sunday, December 17, 2023 7:30:53 PM CET Florian Walpen wrote: > The latency / OSS buffer fragment / blocksize stuff is one of the bigger > blunders I know in our audio stack, and one that can be fixed without > compromising OSS API compatibility too much. > > There's an abstract latency setting through SNDCTL_DSP_POLICY ioctl, the > hw.snd.latency_profile and hw.snd.latency sysctl. It translates to a certain > buffer and fragment size, at 48kHz 16bit stereo. Different ones for > recording and playback. These sizes are then scaled according to the actual > sample rate and frame size, and rounded to a power of two. Which can be > already far off from the intended latency per fragment. > > These buffer and fragment sizes are then further processed, limited and > rounded (power of two) again. They end up as the fragment size of the > internal buffers. Funny enough, the fragment size is almost meaningless, > apart from defining the default low water mark. Less funny that it is also > communicated as blocksize to the driver, to set a certain latency. At this > point it's a bit of a lottery because the driver has its own rounding > requirements (e.g. milliseconds), and it depends on whether recording or > playback blocksize has the final say. Because drivers typically need the > same blocksize for recording and playback. > > Some of the drivers have dedicated tunables to get predictable blocksizes. > Yes, that's what hw.usb.uaudio.buffer_ms is for. > > So at least it would be nice to get a consistent latency hint at the driver > level. The effective fragment size for the front side buffers should be set > according to what the driver uses, not the other way round. > Bonus points if we find a way to set the buffer size from an application, > without the obsessive power-of-two-rounding. Addendum: From my work on the snd_hdspe(4) driver I can say that the issue of inconsistent buffer size / fragment / blocksize is not only a problem for developers (application and drivers), but also causes playback stuttering for some configurations. AFAICT this is due to vchan feeders not adapting to what the driver reports as blocksize. I also remember that snd_hda(4) playback began to stutter when I tried to adjust its buffer size from an application. In hindsight it's plausible that this is the same issue. It made me give up completely on doing OSS API buffer size adjustments in applications. Florian