Date: Thu, 25 Jan 2024 23:25:43 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 276607] audio/jack: artifact noises, "Write buffer balancing", mixed rtprio Message-ID: <bug-276607-7788-SSfXfUHTeX@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-276607-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-276607-7788@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=3D276607 --- Comment #1 from Florian Walpen <dev@submerge.ch> --- One question first: Do you know about mac_priority(4)? Is there any reason = not to give the designated Jack user realtime privileges? I'm thinking about removing the whole rtprio hack from the RC service file. Which should be possible now that all supported versions of FreeBSD have the mac_priority module. Going realtime would then be: 1. Add designated Jack user to the realtime group. 2. Change "jackd_args" in rc.conf to use realtime mode ("-R ..."). Am I missing something? =3D=3D Context =3D=3D The default way to start Jack is now through the DBUS interface (jack_contr= ol), on demand. While I do not use the RC service anymore, I appreciate its usefulness and I'm willing to support it, as long as it works - against the recommendation of upstream. But both the Jack server and the whole Jack ecosystem are now built on the assumption that threads can gain (and drop) realtime priority independently= and by themself. Consequences are that - Not all threads of the Jack server and its clients _should_ have realtime priority - Threads will drop realtime priority and try to regain it later when need= ed I'm sure that having only Jack server started with realtime priority can ha= ve positive effects in certain scenarios (like yours). But without the clients getting realtime priority too, its usefulness is limited. And it leads to problems similar to bug #263373. That's why I'd like to get rid of the rtpr= io hack completely, in favor of the more consistent user realtime privilege. =3D=3D About Buffer Balancing =3D=3D The buffer balancing in Jack is an attempt to correct uneven progress betwe= en recording and playback channels. It does so by manipulating the playback channel, filling gaps or dropping samples. Please note that this can be both the cause or a symptom of the audible "knacks". And yes, sometimes it overreacts. The upcoming version of Jack will have a different approach. Apart from realtime priority, there's some other possible workarounds: - Start Jack without a recording device, if you don't need it - Drop CPU intensive workloads to lower priority (e.g. run poudriere with = idle priority) - Disable vchans and go bitperfect if Jack is the only consumer of the dev= ice - Go for smaller blocksize of the device (hw.snd.latency, hw.usb.uaudio.buffer_ms) - Make the Jack period a multiple of the blocksize (depends on your hardwa= re) --=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-276607-7788-SSfXfUHTeX>