From owner-freebsd-multimedia@freebsd.org Sat Dec 5 16:27:01 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 CCBCD4A11E0 for ; Sat, 5 Dec 2020 16:27:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4CpFMn5FDNz3wBZ for ; Sat, 5 Dec 2020 16:27:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id B22BF4A1308; Sat, 5 Dec 2020 16:27:01 +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 B1F7C4A11DF for ; Sat, 5 Dec 2020 16:27:01 +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 4CpFMn4ZG7z3wK2 for ; Sat, 5 Dec 2020 16:27:01 +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 908A120C2B for ; Sat, 5 Dec 2020 16:27:01 +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 0B5GR1Nh094269 for ; Sat, 5 Dec 2020 16:27:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0B5GR1pS094268 for multimedia@FreeBSD.org; Sat, 5 Dec 2020 16:27:01 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: Sat, 05 Dec 2020 16:27:01 +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: Sat, 05 Dec 2020 16:27:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251125 --- Comment #58 from Florian Walpen --- (In reply to Goran Meki=C4=87 from comment #55) > What is next? Are we satisfied with how it looks? > If yes, should we upstream it (squash it first?), if no, what should we w= ork on? I'm not a port maintainer, but I would propose to fetch from your repo temporarily for the FreeBSD port - give it some more exposure and testing on the FreeBSD side, make sure we have most use cases covered. It will be hard enough to get it upstream once. As for commits, I would keep the build fixes separately, and squash the dri= ver fixes to meaningful chunks before going upstream. What still concerns me is the ordering of the ioctl calls. AFAIK the origin= al order was according to http://manuals.opensound.com/developer/callorder.htm= l, and we should probably keep it that way for non-FreeBSD use. The main confl= ict lies in SNDCTL_DSP_SETFRAGMENT order, right? Or is there any other ioctl we should call in different order on FreeBSD? Current implementation does: SNDCTL_DSP_COOKEDMODE SNDCTL_DSP_CHANNELS SNDCTL_DSP_SETFRAGMENT SNDCTL_DSP_SETFMT SNDCTL_DSP_SPEED SNDCTL_DSP_GETBLKSIZE --=20 You are receiving this mail because: You are the assignee for the bug.=