Date: Mon, 30 Nov 2020 13:07:54 +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-rQnxV8ZiNJ@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 #39 from Florian Walpen <dev@submerge.ch> --- Thanks for the log, Goran. For me the block size returned was always the fragment size requested (minus 3 byte rounding for 24bit samples). Obviously the block size of 36864 fits your settings (512 * 4 * 18). But what confuse= s me is how you get a non-2^N fragment size - maybe it just uses a multiple of t= he page size for bigger fragments? Probably HPS knows, or I'll have a look at the source code later on. What helped in my case was to go the other way round and adjust the period parameter in the jack config (both driver and internals). So you could aim = for 2^15 block size, which makes 32768 / (4 * 18) =3D 455 frames per period. No= t sure every jack client will like this odd period size, but in my quick tests Hydrogen, MusE and Ardour6 worked. Don't forget to revert to the original fragment calculation if you try this. I will do more testing as soon as I can fetch my oddball gear from the music room - 6 in 6 out 24bit, and 10 in 12 out 32bit. --=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-rQnxV8ZiNJ>