Provide jack
In order to package pro-audio applications, it is very important to be able to connect to the jack server.
Activity
mentioned in merge request !2427 (merged)
Because it does not make sense. There are two jack implementations: jack1 and jack2. You need a client that can talk to the jack server. And jack being an interprocess audio & midi patch bay, it needs to be the same for all clients.
What is standard about jack is the API & ABI of libjack.so.
Also to me the key aspect of flatpak is to provide the runtime, so to me, it is natural that flatpak provides jack.
I understand it is a bit difficult for you to provide jack because of the jack1 vs jack2 thing. I'd suggest then to have both in the runtime, and depending on what the host system use make the switch between jack1 or jack2.
In case of doubt, select jack2.
Edited by Alexandre BiqueJACK maintainer here.
As JACK runs as a system service, it cannot be made into a flatpak (or any similar packaging format). It is similar to pulseaudio, Xorg or any other system-wide service.
While it could in theory be possible to self-contain a version of JACK within an application's flatpak, doing so would make it impossible for other JACK applications to connect to it, going directly against the design and goals of JACK.
If a system-wide library dependency is not possible, we can use a dlopen() approach to make the dependency optional. Are flatpaks allowed to open system libraries like that though? (honest question, I don't know the limitations imposed by it)
Oh and another thing since I just see mentioned that other applications already have libjack in their flatpaks.. PLEASE do NOT do this. A specific libjack version needs to match what is running system-wide, as protocols, data size and other things change. For example, JACK2 v1.9.13 added meta-data support and next release of JACK2 will increase the default number of ports and clients allowed at runtime. An old libjack.so that tries to talk with an mismatched JACK server will certainly lead to crashes.
Please never ship libjack.so* in flatpaks. Thank you.
Note the only thing needed here is to provide libjack, not the jack server itself (as @falktx said the jack server is a systemd wide service);
The idea is to provide that thorugh the pipewire-libjack library, which is meant to be a dropin replacement of the libjack library (still not 100% complete though) See https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK and https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK
Merge request linked to this issues is implementing just that, see !2427 (merged)
You cannot provide libjack with the application though, because it has internal data and protocols that change depending on the server. libjack.so.0 from jack1 cannot talk to a jack2 server, or pipewire. the library is tighed into the jack server build (not just the version, the actual build, because jack can be built with different feature-set)
There not a single libjack that work across jack servers. The only exception would be if you do a custom libjack that gets out of the sandbox to find the real libjack and talk with that.
Here's a more clear view on why. See https://github.com/jackaudio/jack2/blob/develop/common/JackLibGlobals.h#L57 Which has:
JackSynchro fSynchroTable[CLIENT_NUM];CLIENT_NUM is a compiler macro defined at build time, which can be changed by the developer or distribution. Changing this value will change struct size and pointers.
A bit below you can see that this is created as a static object.
static JackLibGlobals* fGlobals;This is for libjack, not the server.
A few weeks ago I bumped the default number of clients and ports, because the values were too low and done in a time where RAM was not so abundant. https://github.com/jackaudio/jack2/commit/3c7d23f0f29015257e622ff63c0369abf23d0857
The library side assumes the server is running with the same build options. As it always been that way before. I would have to look deeper to find where that can be proved in the code, but anyway, I already had the issue before that a change in a JACK update needed all users to kill and restart JACK. Made a sorta public announcement back then: https://kx.studio/News/?action=view&url=changes-in-kxstudio-repos-regarding-carla-and-jack2
It is out of scope of the JACK project to ensure different versions of libjack and the jack server work together. They MUST be from the same exact build. Anything else is unsupported.
Maybe something like https://github.com/x42/weakjack could be an option? The applications would have to be modified to build against it though.
I am pushing for jack because, to release Bitwig Studio as flatpak application, it is important that we achieve the same level of quality, features and desktop integration as the .deb distribution.
Edited by Alexandre Bique@falktx The Pipewire developers obviously think, they can implement a jack compatibility layer, so maybe you should raise your concerns with them? https://gitlab.freedesktop.org/pipewire/pipewire/
Edited by Peter EszlariI don't have any concerns myself, I do not personally use flatpaks. I am just providing information here for people that do.
with pipewire there is likely going to be the same issues anyway. you cant expect libjack-pw.so to work with a mismatched version of the pipewire "jack server". at least not while pipewire is still in very active development.
With PipeWire you could add a copy of the libjack-pw.so (and libpipewire.so) into the flatpak, I made a promise that it is ABI/API stable.
But, I don't think that's a good idea. I think it's a better idea to add a symlink into the flatpak that links to the system libjack.so version. This way you can run the flatpak on top of PipeWire or real jack, with the parameters you compiled it with. I would hope that's possible.
I don't know. There are opinions that pipewire-jack can work if it will be added to runtime and host will have pipewire-jack server 0.3+.
There are also existing apps on flathub that use jack so somehow people who maintain them must believe they work.
Example of a happy user: https://github.com/flathub/org.shotcut.Shotcut/issues/4
Do you have the link to their flatpak packaging sources? AppImage and Snap are there through: https://github.com/mltframework/shotcut/tree/master/packaging/linux
Source are avalaible in github: https://github.com/search?q=org%3Aflathub+jack&type=Code
@eszlari are you kidding me? This package is doing exactly what should not be done: https://github.com/flathub/org.shotcut.Shotcut/blob/master/org.shotcut.Shotcut.yaml#L131
According to our discussion, this package might only be working on a few system out of luck.
And even if that was the right way to get jack (which it is not), then it should be provided by the freedesktop-sdk.
Edited by Alexandre Bique
To summarize the whole discussion, and please correct me if I am wrong.
The ideal solution would be:
- The package should express somehow that it is using jack, maybe with --socket=jack?
- Flatpak would "copy" the system libjack.so into a path accessible by the application and make sure that the dynamic linker will find it. Ideally /usr/lib/libjack.so, anyway for BitwigStudio if the library is reachable by searching LD_LIBRARY_PATH, we'll find it.
- If jack.so is not present on the host system, do nothing.
- The host's jack.so needs to be watched in order to make sure to keep it in sync in case of a distribution update.
Edited by Alexandre BiqueThis is not possible. We cannot know if
libjack.sofrom the system is compatible with the runtime in Flatpak. For example, if you have a very fresh distribution with a newer glibc than the runtime an application uses, then it might break. Even just the abi from GCC. For example if libssp is enabled on host.
