Jack bump and a realtime guide

Hello everybody! As you can see, I wasable to actually do the job I wanted to do: JACK and a few related packages are now bumped in portage to newer versions, with especially cleaned up ebuilds. JACK itself features a quite slicker ebuild, with fixes here and there for automagic dependencies and similar, and netjack now works fine with multilib-strict. Qjackctl instead gained a desktop file, which now make possible to start it from a menu compatible with FreeDesktop.

I’m still pondering a bit about some of the things present in the jack ebuild, so you’ll probably see a revbump in the next future, for instance the dynamic simd code, sounds to me like it should be dependent on a set of useflags, and absolutely not into the /proc/cpuinfo content, but I’ll have to dig into the code deeper to understand what it actually does in JACK; I hoped to split netjack out on its own ebuild, especially since scons gives me creeps, but it wants some internal data, and even if I provided the headers to netjack, you’ll have to rebuilt it at every jack bump, so it’s not suggested.

You’ll also find some riceitdown patches around that removes use of -O3 and similar flags, so that what you get is what you asked for exactly. Hope this is appreciated.

For those people suggesting me to use the proaudio overlay to get jack, I can tell you that the ebuilds in proaudio leave a lot to desire; they are not in sync with their portage copies, and they features a lot of QA violations, which makes it not suitable for the faint of heart. The changes for sys-libs/pam are, for instance, pretty much an hack that should not be there in this world.

To fix the remaining issues, with a proper solution rather than an hack, I’ve decided to start working on a realtime guide, that describes how to enable realtime support either with realtime-lsm or through PAM itself. I’ll make sure to complete it and commit new versions of realtime-lsm itself (to provide sane defaults) and of PulseAudio, which will make good use of the new guide on itself.

Let me try to explain better why I don’t think anybody should use proaudio overlay blindly unless they have a totally isolated system where anything can be done: in most default desktop setups, the main user is present in the audio group to be able to access both old-style OSS devices (/dev/dsp) and the new ones used by ALSA (abstracted by alsa-lib most of the time); the default configuration installed by sys-libs/pam in proaudio makes those users able to run realtime priority processes up to value 100, to use nice up to –10, and to lock basically as memory as they want. This is not a sane default.

If you’re curious to see how I would consider this problem solved in a sane way, beside giving a good guide about it, I’ll consider asking the new PAM maintainers (if there are some) to provide in the default a realtime group, which can use realtime priority up to 10 – that should be enough for basic setups. Further fiddling with the values should happen following the guide.

The realtime group idea is not strictly mine, Lennart Pettering told me about it when I first packaged PulseAudio; PulseAudio itself will make use of it, and will soon create it in pulse-rt group stead. This should solve most of the problems without security breaches for most users.

Okay, so now back into writing this guide!