[Bug 276607] audio/jack: artifact noises, "Write buffer balancing", mixed rtprio

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276607

--- 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?


== Context ==

The default way to start Jack is now through the DBUS interface (jack_control),
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 needed

I'm sure that having only Jack server started with realtime priority can have
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 rtprio
hack completely, in favor of the more consistent user realtime privilege.


== About Buffer Balancing ==

The buffer balancing in Jack is an attempt to correct uneven progress between
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 device
 - 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 hardware)

-- 
You are receiving this mail because:
You are the assignee for the bug.