Are you trying to hook Bitwig up to other realtime software with jackd? Because if not-- e.g., you're just trying to output sound from Bitwig with the lowest latency possible-- there is absolutely no point in running jack. Go straight to ALSA.
Note: I'm not familiar with Bitwig and am assuming it isn't a weirdo that somehow prevents you from setting ALSA as the backend on Linux.
The downside to "straight-to-ALSA" is that a realtime prog will gain exclusive control over the audio subsystem. So someone who wants to watch a youtube video demo on realtime prog Z and run realtime prog Z to monkey along will end up with a frozen video as it blocks (or perhaps Pulse blocks) waiting for prog Z to release the audio to it. (Or if the video started first, prog Z will (hopefully) error out trying to gain an exclusive connection to ALSA that it cannot get.)
Pulse is valuable because its default behavior solves this use case. Jack can be set up to do this, too-- I have used Qjackctl or whatever to automate this use case when setting things up. But at least last time I used Jack I had to "opt in" to this obvious setting of "pipe the running stuff to the speakers, please." E.g., I had to do business with my brain and some global mutable state. Not sure if that's changed.
AFAIK ALSA-only distros tend to have SW mixing configured by default and PulseAudio-based distros have ALSA intercepting enabled by default. So in practice an application that needs some basic audio playback can just use ALSA and it'll work everywhere.
"In practice" doesn't mean what you think it means.
The behavior I described was with a Pinebook Pro which only came out about a year ago. That was running whatever version of Debian they shipped-- either stretch or buster, can't remember now. And there was no fancy or custom audio setup-- it was just an XFCE desktop environment with Pulse running however it's configured to run by default.
Also, as a maintainer of realtime audio FOSS software I can tell you users have reported these exact problems on other Linux distros. Over at least the last year and a half.
It appears that in Debian testing the configuration of Pulse "just works" as you describe. I would rankly speculate that Ubuntu 20.04 probably has a similar default setup. But to turn that rank speculation into "in practice" we'd need to actually test and see, and it sounds like neither of us have done that yet.
BTW what i describe is how Debian was for years when i used it by default, not just testing. It is possible that the version of Debian Pinebook Pro shipped was altered. Or something else wasn't configured as i had it, who knows.
It already works better than pulse for bluetooth stuff, by a long shot. wtay is a good guy who is committed to the project, as opposed to the pulse maintainers who are jerks.
That doesn't seem fair to just throw out without proof. In all the interactions I've seen them in, they've come across alright for the most part.
Maintainers unresponsive, talking about making changes but not following up. They strung the guy along for quite a while on this new codec selection mechanism problem. They claim to be in a v14.0 freeze for two months. He updated his code to work on new v14.0 to more unresponsiveness from maintainers about merging. And it goes on from there.
If you've had to use pulseaudio-modules-bt or pali's patched version rather than official pulse, this is why. By comparison, pipewire managed to get it working with little effort because its lead developer is a nice guy and responsive.
Overall a really unfortunate turn of events there. On a personal note I've been watching that space for awhile and was looking forward to Pali's great work on bluetooth.
While I would have wished for a good clean solution from the start, the state of the current Linux Audio stack doesn't IMO really allow for such a solution without breaking every program ever.
If Linux Audio needs one thing it would be something that handles the weird relationships between ALSA/Pulseaudio/Jack in a clear and automatic fashion. Because as for now I have seen Linux Sysadmins with 30 years of experience tear their hair out because they couldn't wrap their head around Linux Audio.
Build a blackbox around it and try to rework it on the inside.
My Linux DAW easily outperforms my Mac DAW, and I have tens of thousands of buckaroos invested in the latter, but only a couple hundred in the former. Ubuntu Studio is simply the best out-of-the-box DAW user experience around.
>If you're writing audio software the solution is to use WASAPI on windows, CoreAudio on Mac, and tell Linux users to use Windows or MacOS if they want low latency audio.
This is nonsense advice. I'll instead tell Linux users to use a decent distro, and target JACK+Alsa for my Linux builds ...
So looking at Pipewire, let's hope for it to make Pro Audio and Consumer Audio interoperable on Linux. Because I really like the flexibility of Jack and the PulseAudio way of user experience.
I had it all working with Pulse + Jack a year ago, on a previous workstation build, but it was a massive pain to get there. I had my m-audio USB keyboard working, along with Tracktion Waveform and VCV Rack. (None of which give tolerable audio quality with vanilla Pulse, even on new Ryzen 5600 + dedicated Sonar audio card.)
Based on the last experience, this time I'll take a snapshot of current .deb packages installed, a full copy of /etc/ and all my dot files (audio stuff seems to be spread far and wide under app-specific ~/. files as well as the expected places ~/.local and ~/.config).
I recall even when it was working, occasional upgrades (albeit Debian unstable) would stop various components, and troubleshooting an audio stack, if it's not something you do regularly, is slow and frustrating work. Referring back to earlier configuration files and package names should make this easier.
First step though is working out again why Debian still has jackd1 and jackd2 packages. The first search result for that question is from 2011, and it sounds like OSS / ALSA is the only reason jackd1 would be preferred. And there you have a fantastic example of how befuddling audio on GNU/Linux can be for the casual user.
Not to mention, neither Mac or Windows come anywhere NEAR the awesomeness that is Zynthian .. and if anything demonstrates the amazing flexibility and power of Audio on Linux, its the Zynthian system.
Simply amazing audio!
This means "I don't want to think about it" installing a whole distro is way too much work for someone with this attitude.
I don't think ASIO has been updated in several years either.
Sidenote, audio stacks are not fundamentally fragmented. DirectSound is deprecated in favor of WASAPI. ASIO only exists because DirectSound sucked, now WASAPI is good enough not to use ASIO moving forward (with some hiccups, like some software doing SRC under the hood because WASAPI doesn't let you programmatically select sample rate - RtAudio does this, for example).
CoreAudio has been stable for almost 20 years. It is the gold standard. The only problem is the almost complete lack of documentation except for the CoreAudio mailing list.
If you're writing audio software the solution is to use WASAPI on windows, CoreAudio on Mac, and tell Linux users to use Windows or MacOS if they want low latency audio.