Bitwig on Linux -- How to avoid common issues

[mwstl]

Here are a couple of notes for those who wish to use Bitwig on Linux, but is not quite explained properly on official documentation.

Unfortunately there isn't a direct fix, but the workaround is very simple.

Stick with Qjackctl, and follow these guidelines, and you will definitely have less issues.

Hopefully these small quirks can be resolved in the future with bitwig updates, but at the current time it suffices to say it affects all distros, so it doesn't matter which distro is being used, this is more of a problem going with Bitwig's handling of auto-enabling jack. The general issues around Bitwig's poor handling of jack are quick to fix, but some users may wish to understand as to why they are enabling things and using a setup with qjackctl rather than other methods -- so that is discussed in a bit without going too much into technical detail.

The instructions are short and simple, the roughness around it is explaining to the reasons and purpose and why it is necessary. Hopefully the following document helps users who are coming to Linux interested in giving Bitwig a try, but ultimately come across similar issues I see frequently here on this forum as well as on bitwig's q&a site.

There's a simple end-goal here and that is to prevent Bitwig from starting up jackd on its own and instead let qjackctl handle the startup of jack.

That's basically the objective outright flat. Plain simple.


By keeping usage primarily with qjackctl, jack problems become less an issue, and Bitwig can therefore work better with it.

As long as a user sticks with qjackctl and doesn't meddle around with things like jack_control or jackd commands, things should generally just work.

....

To start off first, it is important to acknowledge the fact that Bitwig's auto-start of "jackd" is problematic for Linux distributions because by default "pulseaudio" is commonly installed, and that these two would conflict.

To avoid this, simply just stick with Qjackctl, and make sure that,

1) You have all dbus options enabled (there's just two of them)
and
2) Make sure that "Midi handling" is not carried out by Jack by setting its Midi options to ->"None"

Default behaviour on Linux is not having JACK enabled, and JACK can be enabled in various ways.

Bitwig can auto-enable JACK but it auto-enables it with "jackd" instead of the modern "jackdbus".

^ Why is this important to know?

Linux distributions have pulseaudio, and pulseaudio has a special module called "module-jackdbus-detect". This special module does not recognize jackd events, but rather the newer and more modern "jackdbus".

So if Bitwig wants to work better, it should rather instead be auto-enabling jackdbus.

^ To prevent Bitwig from auto-enabling jack on its own, a user just has to stick with the graphical qjackctl interface and just make sure the dbus options are enabled and to press "start" from qjactkctl. Qjactkctl will then enable JACK via jackdbus rather than jackd.

(Do not be confused, this is as far as you need to worry about whether you are dealing between jackd or jackdbus.

Just make sure you've got qjackctl starting the jack instance rather than letting Bitwig do this on its own.)


If you start Bitwig ahead of running qjackctl, then you'll need to close down Bitwig, and any other jack client you started as Bitwig calls jackd with -T, its started jackd instance will automatically close when there are not more clients connected.

^ To simplify and prevent this from happening, a user can simply set the auto-start checkbox in qjackctl and that would start jackdbus everytime the user opens qjackctl, the user then needs to make sure qjackctl is also in their Desktop's autostart -- so every time the user logs in jackdbus is automatically started...

Once you you have jack running(more specifically "jackdbus"), you can then start up Bitwig.

(Bitwig can connect to either jackd or jackdbus, but the ubiquity of pulseaudio already being there means issues when a user is starting up jackd. This is where a lot of users try to find workarounds but the solution is simply ensuring that jackd is not used -- it's as simple as this.)

..

As far as having "module-jack-dbus" not working (which may be rare), the workarounds are rather tedious but not impossible -- two script/command workarounds are provided on this forum -- 1 for jackd users, another for jackdbus. Users should imho preferably go with jackdbus even for this additional scripting workaround as things are generally headed towards dbus system unit files -- and this is where jackdbus gets its auto-activation. Perhaps when the time comes jack3 is released things would become less an issue.(these two script/workarounds are posted somewhere on the forum, just search for "jackd" or "jackdbus" in the search box and you'll see the workaround script/commands with pictures in getting it to work with qjackctl and so on.)

In general these workarounds are not needed, but in case a user may have a quirky system which may need extra workarounds, instructions are there and have been tested by me so I know they work.

Module-jackdbus-detect needs to be installed
------------------------------------------------------------
Normally distros would come bundled with this module file(module-jackdbus-detect.so), if it is not installed then pulseaudio<->jackdbus won't work.

Here on debian, the package name which contains this module is -> "pulseaudio-module-jack",
on fedora/arch systems it would be "pulseaudio-jack"

In general mainstream linux distros include this module so likelyhood that it is not already available is relatively low
(a quick check with "pacmd list-modules|grep jack" would show)
, if it is not then a simple query with your package manager should do the trick, there's not too many packages with the name pulse or pulseaudio in them, and so it should be fairly easy to spot and install.

The audio routing for default linux distros is basically
pulseaudio->alsa

Contrary to some discussion, it is incorrect to state that pulseaudio scans jackd startup/shutdown, it doesn't, and the reason why Bitwig is failing for some users(as I notice on this forum and on bitwig's q&a threads) is because the user is not setting their Qjackctl settings to Dbus -- which consequently makes qjackctl call "jackd" --> which in turn causes conflicts with pulseaudio.

[
Not to get too technical, but the mere situation regarding workarounds has users attempting to manually "load module-jack-sink" while module-jackdbus-detect is still loaded under pulseaudio. Basically what users sometimes do is to kill the jackdbus instance and in effect the module-jackdbus-detect detects this and unloads module-jack-sink leaving pulseaudio without a way to connect to jack. < "pacmd list-modules" will show the loading/unloading of module-jack-sink/module-jack-source.

^ it doesn't need to be difficult if users just remember the 1 rule regarding pulseaudio's module-jackdbus-detect --> it's made for jackdbus, and not jackd.

If a user wants to work with jackd, pulseaudio should not be loading module-jackdbus-detect.
]


3)
The last and final thing you need to ensure is to not use A2J.
You'll know if you're using A2J as you'll need to manually install/start it, but you'll see many guides online telling people to use it in order to fix recognizing their midi devices.

If you are running Bitwig and cannot access midi devices, the first place to check is your qjackctl settings and see that your Midi options are set to ->"None".

Bitwig cannot work with Midi if jack or A2J are handling/remapping the midi so make sure neither of them are doing so.


Overall the procedure is just simple.

hope this helps

thanks

[mwstl]

A last note is the possibility of removing pulseaudio entirely as I know someone will be pointing it out is not an additionally bad alternative.
Users can use alsa-plugin-jack if they wish to in order to avoid any potential conflict with pulseaudio entirely.

^ but that's the role for pulseaudio's module-jackdbus-detect... users just need to make sure they are using jackdbus and not jackd.

A problem though going this alternative route of using alsa-plugin-jack-- is there are a small group of applications such as Firefox which stubbornly still use pulseaudio api and not alsa. There was a workaround patch someone put online about 2 years ago for having Firefox connect to jack directly, but afaict this feature was experimental and seems to no longer be functional as part of the official build. Chromium/Chrome use alsa api, and shouldn't have a problem here.
Instructions for having the alsa-plugin-jack can be found here,
http://jackaudio.org/faq/routing_alsa.html

[Benutzername]

IMHO the best solution if you are using just using one audio application: Screw jackd, ignore Pulse Audio and just use ALSA. No setup hassle, most stable performance, lowest latency, least problems and no need to destroy the default audio system of your desktop environment.

You may have to stop the audio engine when you want to watch a Youtube video while making music but that's not a big deal.

[Benutzername]

dblpost

[wavedigit]

IMHO the best solution if you are using just using one audio application: Screw jackd, ignore Pulse Audio and just use ALSA. No setup hassle, most stable performance, lowest latency, least problems and no need to destroy the default audio system of your desktop environment.

You may have to stop the audio engine when you want to watch a Youtube video while making music but that's not a big deal.

I think this assumes that dmix is present in your ALSA version and that tooling is readily available to mix channels between apps.

[mwstl]

IMHO the best solution if you are using just using one audio application: Screw jackd, ignore Pulse Audio and just use ALSA. No setup hassle, most stable performance, lowest latency, least problems and no need to destroy the default audio system of your desktop environment.

You may have to stop the audio engine when you want to watch a Youtube video while making music but that's not a big deal.

It's easier said than done. The problem is that the mainstream distributions come with pulseaudio installed and the solution is very simple as check-marking 2 dbus options in the Qjackctl interface. The OP was worded to explain as to the reasons as to why it is better to enable these two checkmarks than not. But basically that's all it comes down to it so that Bitwig can run. The other fact is you spoke too soon. Bitwig is not opensource Jack-compliant. It does things that causes issues on all Linux platforms in that it always wants to grab entirely the Midi device. << This means that no other opensource Application can use the same midi device. Whether you are using Alsa or Jack it is the same situation.. You also forgot that Pulseaudio would be left wanting to grab the same Alsa device as Bitwig. If you are going that route, then you should be disabling pulseaudio so that it is not left fighting for the same alsa device.

But the instructions are simple, I just needed to explain the reasons behind them so that users can understand better as to why jackdbus is the proper choice to use for Bitwig rather than going with jackd which is not autodetected by pulseaudio.

It's just two checkboxes... that's what it really comes down to, it's that simple a solution... And users are sometimes instead going to using workarounds to get jackd to work with pulseaudio -- this
is much more complex and imho quite unnecessary.

[EnGee]

Thanks for the detailed info.

Today was day one with Ubuntu Studio (19.04). I have Ubuntu 18.04 installed and configured with Alsa, but I wanted to see how Ubuntu Studio differs. Well, it comes with utility (Ubuntu control) to setup the final touches for Jack server. It's straight forward and easy. So I could run Bitwig with jack.

I haven't noticed a difference with audio performance, but the system is much faster and it seems stable. So day one seems great with Ubuntu Studio

[mwstl]

Thanks for the detailed info.

Today was day one with Ubuntu Studio (19.04). I have Ubuntu 18.04 installed and configured with Alsa, but I wanted to see how Ubuntu Studio differs. Well, it comes with utility (Ubuntu control) to setup the final touches for Jack server. It's straight forward and easy. So I could run Bitwig with jack.

I haven't noticed a difference with audio performance, but the system is much faster and it seems stable. So day one seems great with Ubuntu Studio

that's good, that sets up all the difficult cruft with real-time things in the system.. I suppose those music-dedicated distros do not have pulseaudio installed by default as that would avoid basic problems..

[EnGee]

I think it is installed but you can 'direct' it to Jack. Anyway, Ubuntu Studio is giving me errors when I login about auto-jack. I didn't investigate further, so I return to Alsa.
I don't have a problem with Alsa to be honest. Firefox and other software are using the nVidia HDMI port (which I think it is the PulseAudio) and Bitwig uses Alsa, so I don't have a problem with such configuration. It is kinda similar to what I have in Windows.

[Benutzername]

Ubuntu Studio is doing some more things to the system than just configure jack. It's realtime kernel can help to squeeze the last 5% out of a system but what really helps on all systems is to make sure that the current user is allowed to gain realtime priority. Look at the Realtime Threads section of Renoise's Linux FAQ.

Users have to decide if they really need jackd. At the end of the day jack is using the same ALSA API calls as all the applications that use ALSA directly. The magic of jack is in the routing and synchronization, not in the achivable latency or stability. Jack may internally use some clever optimization tricks but it's still a wrapper on top of the native APIs. When it's used then everything has to go through the jack system and that will cost performance. This will balance itself out so there shouldn't be any noticeable difference in performance with just a single application running.

It's easier said than done.

No it isn't. Just select ALSA as output in any DAW and you are good to go. That's it.

If you want to route audio between applications, create aggregate devices or if you want to mix outputs from different applications then you need to care about jack, PA and how all of this fits together. If you just want to make music in a modern DAW like Bitwig then select ALSA as output and make music. Easy enough.

[wavedigit]

Perhaps a side-question but is it possible to use only ALSA when you want to utilize multiple audio interfaces?

[EnGee]

I didn't delve into the details, but Ubuntu Studio comes with low latency kernel utilized for audio/video production vs real-time kernel in the normal distribution. I don't know though what they mean by real-time kernel. What I know in the past some people chose Gentoo distribution because of everything is compiled before the distro is ready to be used. The advantages are speed and efficiency but I don't know if this relates to low latency kernel.

Anyway, what I understand from this thread (thanks to the participants) is that Jack is mostly useful if someone wants flexibility and/or has only one sound card (for example a laptop) that for multi usages simultaneously. Although, it still can make a modular like environment with different audio/midi applications.

[CasualHobbyist]

@EnGee You can use JACK for multiple audio card interfacing, as described in this link here:
http://jackaudio.org/faq/multiple_devices.html

Is just that it takes more time to setup and fiddle, and one of the easier options shown there is to use something with ALSA drivers by default. (by using alsa_in and alsa_out)

To paraphrase the words of one of u-he developers "You can effectively set up a realtime low latency kernel on Linux, but you can setup music on any distro that you want, Ubuntu is enough for most needs out there", so is definitely an optional thing, I heard it is fun to fiddle with the results and all that if you're curious.

Gentoo is a source-based distro. Which means that every single package is compiled, from the libraries, the compilers, everything! You can gain some performance sure, but at the cost of updates being one of the most time-consuming methods to do unless you come prepared with methods such as distcc or the like to speed up the process, is not for the faint of heart and the project proudly states it. (There are also a few binaries in Gentoo like LO and Firefox because compiling those may take a significant amount of time due to the required dependencies)

[EnGee]

Thanks

Of course you can use any Linux with Bitwig, but for me I think I'm feeling more comfortable with Ubuntu Studio. It is xfce desktop by default so it is snappy and similar to the old Gnome (version 2) which I like Of course not all are greener here! Expect a lot of error messages but they are minor and mostly not related to Bitwig and/or audio production with Bitwig (and this is what important for me really). Still, it is Linux so it begs to be customized

Here is the Ubuntu Studio Control which needs some trial and error till you reach the best configuration for your hardware, but it is easy to use (I'm not using it though now, but it is good to know if needed):

[mwstl]

Just select ALSA as output in any DAW and you are good to go. That's it.

Bitwig does not behave like other DAW applications as it does not let other applications use the same midi device -- it doesn't matter whether you use Jack or Alsa, the midi devices are still going to be locked-in to Bitwig.

Just select ALSA as output in any DAW and you are good to go.

that's a common mistake a lot of users make because they forget that pulseaudio comes by default on mainstream Linux.
(the exception are music distros which avoid having pulseaudio installed)

A simple workaround if a user does not want to reconfigure pulseaudio is to suspend it with "pasuspender".. this way pa is suspended from the time the application starts until it finishes.
( going this route however means you are likely not to have sound for anything other than Bitwig. Whether that is good or bad depends on the user requirement. )

create aggregate devices

^ not sure what you mean by that --- but if you mean asnd-loop/dsnoop devices, maybe you could overcome the single-alsa-client setup if you use Bitwig->alsa --- so that Bitwig can instead go to a virtual substream device of ->{asndloop}->alsa --- still it doesn't mean Bitwig would work properly with it, so you're kind of gambling with this setup (and you also need to consider added latency even if you're trying something similar with pulseaudio or jack)

"It's realtime kernel can help to squeeze the last 5% "
I suppose you are referring to the kernels' scheduling of RT bandwidth -- by default there's a 1-second period window the scheduler balances RT tasks and that 5% is always going to be there as a safety net so that if an RT task is out of control the system is still able to regain control.

The OP basically covers 2 checkboxes and 1 pulldown midi option. The extra info is there because Linux users tend to demand a little background info as to why they are setting things.

thanks