Add Proper JACK Implementation

[Turtley12]

The Audacity/Saucedacity JACK implementation is technically functional, but it is different from most other jack clients, and as some people have described it: "A perfect example of how not to implement a jack client.

Current Behavior

When "JACK Audio Connection Kit" is selected in the Host drop-down, The recording and playback device show the clients currently connected to the jack audio server. Nothing else happens until you start recording.

When you start recording, Sauceacity automatically connects to the jack clients that were selected. It is then possible to switch the connections to other ports, but since Saucedacity is already recording you end up having to cut the first part of the recording and it makes it hard to record that track alongside other tracks. This makes it difficult to use Saucedacity with anything more than the most basic jack setups.

Expected Behavior

When "JACK Audio Connection Kit" is selected as the audio host, Saucedacity should connect to jack, and register input and output ports, but it should not automatically connect to anything.
Then the user can connect Saucedaity to other jack devices, and when they start recording, Saucedacity will respect these connections. Same with playback.

Alternatives

• Enabling "Sound Activated Recording". This gives the user more time to change the connections from what Saucedacity automatically does, but it is still much more of a hassle than it should be, and it means that as soon as you connect to something it will start recording, which isn't ideal in most cases. and still isn't a proper jack implementation.
• Using some sort of pass-through jack client that Saucedacity automatically connects to, and then manually connecting the passthrough client to other clients.

Additional context

This is a problem in the Audacity issue tracker, but the maintainers basically said it was usable how it is and they weren't going to fix it, So I created this in hope that there will be more support for a better jack implementation here.

Applicable Audacity Issues:
audacity/audacity#3553
audacity/audacity#711
audacity/audacity#710

If there is anything I can help with related to this issue, please let me know.

(This issue is a duplicate, just not a duplicate of an existing Saucedacity Issue.)

[generic-pers0n]

Depending on how you see this issue, it sounds like a bug, enhancement, or even both. I find it an enhancement but also a bug too.

With that being said, I'll need to do some research on this issue. I'll treat this as a bug that we should get fixed.

[Turtley12]

Thank you!

I'm curious about the issue, so I looked into it, it appears that the the portaudio incorrectly does the jack connections, the issue isn't in the saucedacity code.

I feel like there are 2 main ways to fix it, either fixing portaudio, in saucedacity's fork or upstream, or directly using the jack api from saucedacity.

Not sure how easy it would be to get the fix into upstream portaudio.

Either way I can't think of a good way to make it part of the current device/host selection system, because the device selection wouldn't be necessary when jack is set at the audio host. This could possibly be confusing to someone trying to figure out how to use saucedacity, and I feel like empty drop-downs wouldn't look great.

What do you think?

[generic-pers0n]

Thank you!

I'm curious about the issue, so I looked into it, it appears that the the portaudio incorrectly does the jack connections, the issue isn't in the saucedacity code.

I feel like there are 2 main ways to fix it, either fixing portaudio, in saucedacity's fork or upstream, or directly using the jack api from saucedacity.

Not sure how easy it would be to get the fix into upstream portaudio.

Either way I can't think of a good way to make it part of the current device/host selection system, because the device selection wouldn't be necessary when jack is set at the audio host. This could possibly be confusing to someone trying to figure out how to use saucedacity, and I feel like empty drop-downs wouldn't look great.

What do you think?

You had me at the idea at using JACK directly. We could add support for multiple audio backends in Saucedacity (this being PortAudio or JACK), but that aside, I feel like we should use JACK directly because we'll have more control than if we use PortAudio.

On the other hand, we can modify our fork of PortAudio to test changes to JACK support. Then we can contribute this upstream so we don't continue to rely on a vendored version of PortAudio.

For device selection, the easiest solution would be to gray it out when JACK is selected. That's not necessarily the best solution, but I guess it works.

[spaetz]

The good thing in Linux DEs is that they move towards Pipewire which can act as Jack/ALSA/Pulseaudio client directly, so on Linux audio backends would become less problematic (and supporting Jack directly sounds feasible). Not sure about Windows.

[generic-pers0n]

I feel like there are 2 main ways to fix it, either fixing portaudio, in saucedacity's fork or upstream, or directly using the jack api from saucedacity.

Actually, using JACK directly will likely become the only option in the future unless we devise our own fix with a new fork of PortAudio or something. A major build system overhaul has been pending for a while now. See #66 for more details.

On the other hand, we should probably refactor our audio engine and related audio I/O code to make things more manageable for something like this...

[generic-pers0n]

The good thing in Linux DEs is that they move towards Pipewire which can act as Jack/ALSA/Pulseaudio client directly, so on Linux audio backends would become less problematic (and supporting Jack directly sounds feasible). Not sure about Windows.

This sounds interesting...