From nobody Tue Aug 20 17:42:37 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 4WpGyH4bFCz5TWSr for ; Tue, 20 Aug 2024 17:42:47 +0000 (UTC) (envelope-from meka@tilda.center) Received: from chubby.tilda.center (meka.rs [109.93.255.137]) (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 4WpGyG5J0lz4Kbc for ; Tue, 20 Aug 2024 17:42:46 +0000 (UTC) (envelope-from meka@tilda.center) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=tilda.center; spf=pass (mx1.freebsd.org: domain of meka@tilda.center designates 109.93.255.137 as permitted sender) smtp.mailfrom=meka@tilda.center Received: from [192.168.111.162] (hal9000.meka.rs [192.168.111.162]) by chubby.tilda.center (Postfix) with ESMTPSA id F078F218BC for ; Tue, 20 Aug 2024 17:42:37 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------tL5Fyunj8mloLjRMjvFP8Fpf" Message-ID: <12507e44-31b9-44dd-afd3-b58f5676af4e@tilda.center> Date: Tue, 20 Aug 2024 19:42:37 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: Making OSSO default JACK option To: freebsd-multimedia@freebsd.org References: <3171426.ZmR5Pbtf01@z240> Content-Language: en-US From: =?UTF-8?Q?Goran_Meki=C4=87?= In-Reply-To: <3171426.ZmR5Pbtf01@z240> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.04 / 15.00]; NEURAL_HAM_LONG(-0.99)[-0.991]; NEURAL_HAM_SHORT(-0.98)[-0.985]; NEURAL_HAM_MEDIUM(-0.93)[-0.933]; R_MIXED_CHARSET(0.56)[subject]; DMARC_POLICY_ALLOW(-0.50)[tilda.center,reject]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:8400, ipnet:109.92.0.0/15, country:RS]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-multimedia@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4WpGyG5J0lz4Kbc This is a multi-part message in MIME format. --------------tL5Fyunj8mloLjRMjvFP8Fpf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/20/24 18:33, Florian Walpen wrote: > Hi Meka, > Nice to hear that it's working! The option is called SOSSO BTW, but OSSO(BUCO) > would sound yummy too. Just to clarify, the high DSP busy percentage was > probably not due to CPU load, but caused by timing difference between playback > and recording channel IO, and OSS buffer restrictions. Ah, I came from a trip recently and I'm still tired, so apologies for the wrong name :D As I read some articles, DSP percentage represents processing+waiting time compared to time corresponding to the buffer size. So naturally, for the same DSP percentage, lower the CPU usage => higher the waiting. > 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, without a > huge buffer that hurts latency. This way it also gets rid of the timing > dependencies between playback and recording. > > 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. 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. > As for JACK, I'd like to get some more feedback before we turn SOSSO into the > default option. But I did hear you ;-) I see my Subject: is wrong on many levels :o) I meant "making it default in the future" but the fatigue got me. Anyway, yes, I didn't mean jump on it this instance, it's just a bad wording. > Good luck and success with your album recording! 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. Regards, meka --------------tL5Fyunj8mloLjRMjvFP8Fpf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 8/20/24 18:33, Florian Walpen wrote:
Hi Meka,

Nice to hear that it's working! The option is called SOSSO BTW, but OSSO(BUCO) 
would sound yummy too. Just to clarify, the high DSP busy percentage was 
probably not due to CPU load, but caused by timing difference between playback 
and recording channel IO, and OSS buffer restrictions.

Ah, I came from a trip recently and I'm still tired, so apologies for the wrong name :D As I read some articles, DSP percentage represents processing+waiting time compared to time corresponding to the buffer size. So naturally, for the same DSP percentage, lower the CPU usage => higher the waiting.

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, without a 
huge buffer that hurts latency. This way it also gets rid of the timing 
dependencies between playback and recording.

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.
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.
As for JACK, I'd like to get some more feedback before we turn SOSSO into the 
default option. But I did hear you ;-)
I see my Subject: is wrong on many levels :o) I meant "making it default in the future" but the fatigue got me. Anyway, yes, I didn't mean jump on it this instance, it's just a bad wording. 
Good luck and success with your album recording!

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.

Regards,
meka

--------------tL5Fyunj8mloLjRMjvFP8Fpf--