GMaq wrote:
if you use Qjackctl it will automatically start JACK, the PulseAudio JACK sink/source Bridges and a2jmidid when Qjackctl starts JACK.. in this scenario won't the BuB JACK connectivity allow it to work?
BB works fine with JACK. The problem is that BB also supports outputting via ALSA directly, and pulse audio, jack, and/or pipewire can block that access, even when the latter aren't actually making sound. They just grab ahold of the audio hardware, won't give it up (short of the enduser manually killing these servers), and block direct access to the hardware.
Now, there are supposedly ways to tell these servers to let go of the hardware, and BB employs these methods. But the problem is:
1) Each piece of crap software uses a different method to do the same thing. For example, PA uses a proprietary DBUS interface, whereas jack uses a entirely different command written to a shared pipe. With Windows or MacOS, Microsoft and Apple decide how a certain thing is to be done, and that's that. With linux audio, everyone is constantly reinventing the wheel, with no thought to real-world practice, or standardization. Worse, linux audio devs have the inexplicable need to write invasive, trojan-like software that does bad practices like surreptitiously reroute a program's input/output through a completely different code path... without the program's knowledge/approval. You do that shit on Windows/MacOS, and MS/Apple will yank your software from their app stores, and make sure every antivirus program adds your software to their trojan database.
2) There is so much shit software out there that usurp the operating system's job of managing access to hardware, and starting/stopping services. (ie, Servers that "emulate" other servers, bridges, session managers). So depending upon what a person has added to or setup on his system, a "request to unblock the hardware" may or may not work. It's a total crap shoot. This is what makes linux audio so difficult to use. This fragmentation, combined with lots of bad software design, make it pretty much impossible for a developer to troubleshoot an enduser's system, unless the dev can gain direct access/control of the computer to diagnose which piece of crap software is causing the problem.
3) There is no #3 because #1 and #2 are bad enough.
If you want BuB to work across the board you are going to have to deal with either making friends with Pulse/JACK/PW or giving the User a mechanism to connect to ALSA directly and suspend the other servers.
BB does both. And sometimes it works. It depends upon a given user's system. And when something doesn't work, I just advise the enduser not to bother trying to troubleshoot it (because odds are that it's due to bad software design that can't be fixed unless the guy knows how to write software). For example, zonk tried to setup BB to use alsa directly, and something is preventing BB from accessing the audio hardware via alsa. I didn't bother wasting his and my time chasing after audio ghosts. I just noted my own tests which reveal that, whenever I encounter this problem, I've found that 99% of the time the problem is jack, pulse audio, or pipewire. So I told zonk, "Forget about setting BB to use alsa directly on your system. Just giveup and set it to use jack. That will work, and it's probably the only option that will do so on your system."
Mind you, BB uses alsa directly on my system. But I have made sure that jack, pa, and pipewire can't even startup on my system until I manually allow them. I treat them like trojans, which I consider them to be.