Date: Sat, 05 Dec 2020 16:27:01 +0000 From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 251125] audio/jack: update to jack2 or add new port audio/jack2 Message-ID: <bug-251125-12827-qszOc0mKyb@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251125-12827@https.bugs.freebsd.org/bugzilla/> References: <bug-251125-12827@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251125 --- Comment #58 from Florian Walpen <dev@submerge.ch> --- (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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251125-12827-qszOc0mKyb>