From owner-freebsd-multimedia@freebsd.org Fri Dec 4 15:17:36 2020 Return-Path: Delivered-To: freebsd-multimedia@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4323E4A3586 for ; Fri, 4 Dec 2020 15:17:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Cnbt81FStz4qyX for ; Fri, 4 Dec 2020 15:17:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 28F8E4A3585; Fri, 4 Dec 2020 15:17:36 +0000 (UTC) Delivered-To: multimedia@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 28BA54A3322 for ; Fri, 4 Dec 2020 15:17:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cnbt80bfCz4qw9 for ; Fri, 4 Dec 2020 15:17:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 081DA58C8 for ; Fri, 4 Dec 2020 15:17:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0B4FHZXI082351 for ; Fri, 4 Dec 2020 15:17:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0B4FHZcW082350 for multimedia@FreeBSD.org; Fri, 4 Dec 2020 15:17:35 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 251125] audio/jack: update to jack2 or add new port audio/jack2 Date: Fri, 04 Dec 2020 15:17:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dev@submerge.ch X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 15:17:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251125 --- Comment #48 from Florian Walpen --- (In reply to Hans Petter Selasky from comment #46) > There is: >=20 > SNDCTL_DSP_SETBLKSIZE I've seen that in the FreeBSD sources, but it sets fragment count to 2 and = ends up in the same chn_resizebuf(...) as above, rounding fragment size to 2^N a= nd then aligns it to frame size. I'm not using Virtual OSS unfortunately, but Goran does, I think - it may be worth a try as Virtual OSS seems to be more flexible in this regard. But th= is IOCTL is specific to FreeBSD and Virtual OSS I think. > A fragment is usually the smallest entity the audio driver can process. W= ith > USB audio this entity is fixed and can be slightly controlled by > hw.usb.uaudio.buffer_ms to 2,3,4,5,6,7 or 8 ms. In that case it would be best to leave the predefined fragment size as is, right? But we'd have to make sure that jack doesn't block for too long, the= re must be enough fragments to hold the jack period (twice). I have to check t= his. > Other drivers select the buffer size given by the user. This also depends= on > the use of vchans. Bitperfect mode is different, as you know. I suppose we should set the fragment size there. A strategy could be to div= ide the total buffer size into 8 fragments for longer period cycles, and 4 fragments for short periods, if there is no matching fragment size. --=20 You are receiving this mail because: You are the assignee for the bug.=