From nobody Sun Aug 25 18:24:21 2024 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 4WsMf175Txz5TH2T for ; Sun, 25 Aug 2024 18:24:25 +0000 (UTC) (envelope-from dev@submerge.ch) Received: from pianosa.iway.ch (pianosa.iway.ch [212.25.24.37]) (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 4WsMf03z5tz45qb for ; Sun, 25 Aug 2024 18:24:24 +0000 (UTC) (envelope-from dev@submerge.ch) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of dev@submerge.ch designates 212.25.24.37 as permitted sender) smtp.mailfrom=dev@submerge.ch Received: from pianosa.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 812E7E0826 for ; Sun, 25 Aug 2024 20:24:21 +0200 (CEST) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/11471.13121); Sun, 25 Aug 2024 20:24:21 +0200 (CEST) Received: from interway.li (sendai-sued.iway.ch [212.25.24.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pianosa.iway.ch (Postfix) with ESMTPS for ; Sun, 25 Aug 2024 20:24:21 +0200 (CEST) Received: from [145.40.196.39] (account fw@submerge.ch HELO z240.localnet) by sendai-sued.interway.li (CommuniGate Pro SMTP 7.1.0) with ESMTPSA id 248536676 for freebsd-multimedia@freebsd.org; Sun, 25 Aug 2024 20:24:21 +0200 From: Florian Walpen To: freebsd-multimedia@freebsd.org Subject: Re: Making OSSO default JACK option Date: Sun, 25 Aug 2024 20:24:21 +0200 Message-ID: <4493160.Iv3B0QcHgC@z240> In-Reply-To: <12507e44-31b9-44dd-afd3-b58f5676af4e@tilda.center> References: <3171426.ZmR5Pbtf01@z240> <12507e44-31b9-44dd-afd3-b58f5676af4e@tilda.center> 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: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.89 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:212.25.0.0/19]; RCVD_IN_DNSWL_LOW(-0.10)[212.25.24.37:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:8758, ipnet:212.25.0.0/19, country:CH]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-multimedia@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[submerge.ch]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4WsMf03z5tz45qb On Tuesday, August 20, 2024 7:42:37 PM CEST Goran Meki=C4=87 wrote: > On 8/20/24 18:33, Florian Walpen wrote: > > One of the achievements in the new JACK sosso backend is the decoupling= of > > JACK period from the OSS processing interval. The mmap'ed IO and a > > rigorous > > progress measurement let JACK and OSS process at their own pace, withou= t a > > huge buffer that hurts latency. This way it also gets rid of the timing > > dependencies between playback and recording. > >=20 > > With some assistance from the kernel it should be possible to simplify = the > > progress measurements and implement the decoupling method in other sound > > servers and applications on FreeBSD. We'll see how that goes. >=20 > I do intend to learn how mmaped IO is done, at least just enough to > understand what you did for SOSSO. I guess before that I'm not in a > position to understand it all. In principle it's easy - you get some shared memory from mmap() where you c= an=20 read recorded audio data from or write playback audio data to. The shared=20 memory corresponds to the cyclic OSS buffer (bs) in the kernel. From time t= o=20 time you check the _GETIPTR and _GETOPTR ioctls to get the current recordin= g /=20 playback position of the OSS buffer. Keep track and compare that position with the position the application last= =20 read from / wrote to, and read the newly available recording data or write= =20 more playback data into the newly available space. It's getting difficult when you want to measure the progress of the mmap'ed= =20 recording and playback position in time, accurately enough to manage latenc= y=20 within +/- 1ms. There's no wakeup signals from poll(), the application has = to=20 set timers for wakeup. As I explained to Christos in a review: Time-based approach from simple (OSSv4 example) to sophisticated (sosso): - Let the application wake up every e.g. 4ms, and process all audio data=20 available. Works with non-blocking read() / write() or mmap'ed io. - 4ms is too coarse to control the latency within +/- 1ms, wake up at 0.3m= s=20 intervals to synchronize with the driver writes / reads from the buffer. - 0.3ms is too many wakeups, only synchronize at certain intervals (Jack=20 period, e.g. 4ms). Requires one wakeup before the driver writes / reads, on= e=20 wakeup 0.3ms afterwards. - Make synchronizing more efficient (less wakeups) by predicting the next = chunk=20 of driver write / read. - Require multiple successful synchronizations at start, after under- and= =20 overruns, and other irregularities like USB data loss. If implemented correctly, this method achieves very precise synchronization= =20 between the driver and system time, depending on the wakeup precision of th= e=20 system scheduler. This is measured separately for recording and playback, a= nd=20 then one of them (usually recording) can be used as the master to correct=20 drift on the other. As mentioned, the progress measurement could be done in the kernel, just ta= g=20 the OSS buffer progress with some timestamp and make that available to the= =20 application. It would greatly simplify the sosso approach described here. >=20 > > Good luck and success with your album recording! >=20 > We do intend to make it CC licensed (just like the first album), so it > might be good showcase for FreeBSD in the future. We'll see. Make sure to send me a link when it's ready. =46lorian