Skip to content

Conversation

NexAdn
Copy link

@NexAdn NexAdn commented Nov 26, 2022

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

@NexAdn NexAdn changed the title Add JACK support WIP: Add JACK support Dec 2, 2022
@NexAdn
Copy link
Author

NexAdn commented Dec 2, 2022

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.

@NexAdn NexAdn changed the title WIP: Add JACK support Add JACK support Dec 2, 2022
@NexAdn
Copy link
Author

NexAdn commented Dec 2, 2022

Okay, that was actually pretty easy. Let me know what you think.

NexAdn added 4 commits January 4, 2023 22:12
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.
@vifino
Copy link

vifino commented Jan 11, 2023

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>

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.

Copy link
Author

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).

@NexAdn
Copy link
Author

NexAdn commented Feb 25, 2023

Hey! I'd love to see this merged as I use JACK/Pipewire! :)

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.

@bapch
Copy link

bapch commented Sep 19, 2023

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.

@leafblowersama
Copy link

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.

@maximeborges
Copy link

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)

@mkovero
Copy link

mkovero commented Dec 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JACK audio backend support
7 participants