-
-
Notifications
You must be signed in to change notification settings - Fork 54
Add JACK support #60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Add JACK support #60
Conversation
I'm gonna try to make the JACK integration optional at configure time, so people aren't required to have libjack installed for OSM to work. The rest of the PR can be considered ready for review. |
Okay, that was actually pretty easy. Let me know what you think. |
The new JACK plugin requires the libjack-dev at compile time.
This commit adds a JACK plugin, allowing OpenSoundMeter to run with JACK or PipeWire as sound server. This can eliminate problems when OpenSoundMeter is run alongside a sound server which wants to have exclusive access to the sound card. This introduces libjack and the JACK headers as a new dependency on Linux. The JACK plugin differs from other plugins in the sense that it does not automatically establish connections to devices. Instead, each opened stream (be it a measurement or a generator signal) spawns a new JACK client with each of the inputs/outputs required by OSM present as a JACK port. The user can then patch these ports freely in JACK, allowing for freedom in the audio routing. As new JACK clients are spawned upon request, this plugin does always show only a single JACK device in device lists as more is not required and avoids additional complexity when trying to do more elaborate listings. Closes: psmokotnin#58
As JACK is not installed on consumer Linux systems, adding unconditional JACK support introduces an unnecessary dependency for such systems without bringing any benefit. This commit makes JACK support optional at configure-time, so users can configure whether they want integrated JACK support or not.
Since the JACK integration shall be built in the CI pipeline, this commit sets the jack config option in the qmake call in the Travis configuration.
Hey! I'd love to see this merged as I use JACK/Pipewire! :) |
#include <QObject> | ||
#include <functional> | ||
#include <jack/jack.h> | ||
#include <jack/types.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems unfortunate that the jack headers are included in this header, which in turn is included in client.cpp. It would be better if the external jack header dependency was fully contained in plugins/jack.cpp . That seems feasible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't consider this a big deal. The JACK headers are lightweight and the headers aren't provided as part of a library for other software, anyway. There is no big advantage keeping them away from the plugin's header file and keeping them contained in jack.cpp brings the additional issue of moving the class definition for JackClient to the source file, which is opposed to the code style from the ALSA plugin (which was my template for developing this plugin).
I don't know how long until I get any reaction for this PR or the accompanying issue from Pavel. For now, I've taken the freedom to provide a patched version with this feature and the ALSA deadlock fix applied in Gentoo's GURU repo. If you'd like to have these patches applied, you could ask your distro's package maintainer to apply those patches for their version as well. While it's not the fine way, it doesn't look like upstream is going to apply those patches anytime soon and at least one of them is critical for stable operation of the whole program. |
Hey @NexAdn, thanks for the PR ! At the moment, when the generator is disengaged, it disappears as a jack client. Would it be hard to make it stay ? No big deal though because we could use the jack patchbay to make it automatically reconnect to the right output. |
Thanks for the PR ! Did anyone get any feedback on whether this is likely to be merged anytime soon ? FWIW it works flawlessly on my end and I'll gladly be using it, hope it gets upstreamed. |
Same question, any update to get that merged? Most modern distros are switching to pipewire which has a compatibility layer for JACK, and having proper support for JACK would allow a very large support on more complex hardware (and would allow routing and filtering from outside OSM) |
I copied this to the latest bits and it works beautifully, definitely recommend if using OSM in linux with pipewire and/or jack!) (757812). ALSA option was completely unusable for me latency-wise. |
This PR introduces support for the JACK audio backend on Linux,
which is the pro audio backend normally used on Linux.
This also allows the application to run under PipeWire,
a new audio backend which is becoming popular in major Linux distributions,
thus allowing the program to run under most audio setups without any problems associated with directly accessing the sound card using ALSA.
Closes #58