Jackd on Linux - Midi input fix

Official support for: bitwig.com
RELATED
PRODUCTS

Post

A new user here with bitwig, .. I was not getting MIDI input(keyboard instrument) and want to share a small tip to help for those needing to get MIDI working.. I'm a little startled as to why this is not mentioned in the documentation somewhere, as bitwig does not behave like an ordinary opensource jackd client, ...

the tip is simple

-> don't use -X with jackd, otherwise bitwig will not be able to set MIDI input.

-> problem is other applications such as "ardour" would need it in order to be able to pick up MIDI.

For me this is not a problem, and probably there are users who found out better ways to solve this, but for me atm it works fine enough as a basic setup as I get the hang of bitwig..

Jackd is also started by bitwig, .... while I was troubleshooting this, I noticed that if "jackd" is not instantiated already(and your audio settings in Bitwig is set to jackd), then it will automatically run "jackd -T" in the background. The -T option here is to close jackd after all clients have disconnected..

The problem here, is that bitwig does not care what is set with your "~/.jackdrc" settings and will let jackd launch with its own settings from its configuration file ->"~/.jackdrc" and nothing else..

This means, that if you have something like -Xseq set inside ~/.jackdrc, here bitwig is unaware that this option prevents it from picking up MIDI properly.

The workaround is to take out -Xseq from ~/.jackdrc, or use a front-end interface like qjackctl to toggle on and off that option.

Bitwig does not check for this, ... and despite all my search into the MIDI settings, there's nothing that will allow to input a jackd line ... it basically just calls jackd and lets jackd take care of itself..

This is simple from a developer's point of view, but users who don't know and may wonder why MIDI input does not work should take note..

I use -Xseq for ardour, and I guess there must be ways such that I can use ardour and bitwig at the same time... but I'll have to look into that later..

thanks

Post

Thanks for posting your tips. It could help someone in the future when they find it doing a Google search.

Post

mwstl wrote: Thu Aug 15, 2019 3:30 pm The problem here, is that bitwig does not care what is set with your "~/.jackdrc" settings and will let jackd launch with its own settings from its configuration file ->"~/.jackdrc" and nothing else..
Yep. So always have jackd started automatically at boot, with your params. And that's it.

By installing the jacksink for pulseaudio, pulseaudio will start jackd automatically at boot using ~/.jackdrc.

It's that simple.

My ~/.jackdrc at boot is (1010LT PCI card audio interface) :

Code: Select all

/usr/bin/jackd --sync -P80 -ndefault -dalsa -dhw:M1010LT -r44100 -p512 -n8
Which is OK for most uses except when recording acoustic guitar while monitoring through the headphones, in which case I want less latency:

Code: Select all

/usr/bin/jackd --sync -P80 -ndefault -dalsa -dhw:M1010LT -r44100 -p256 -n4 
i5-3570 CPU @ 3.40GHz, 16 GB RAM., Xubunbtu 18.04 LTS, Bitwig 2.4.3

Of course, when running Mixbus32C (Ardour) for mixing/mastering I have to quickly alter this config using an alias, so I can use a Faderport with Mixbus32C:

Code: Select all

alias A2J='a2j_control ehw start
And when I go back to Bitwig, another alias :

Code: Select all

alias KA2J='killall /usr/bin/a2jmidid'
One of these days I'll incorporate those two into the launcher icons for these DAWs.

Cheers.

Post

thanks mevla but I noticed a thing or two with your setup... I'm not super pro, but I noticed that your hardware is able to do 96khz and you're actually downgrading your sampling to 16-bit when it could be higher...
mevla wrote: Fri Aug 16, 2019 11:06 pm

Code: Select all

/usr/bin/jackd --sync -P80 -ndefault -dalsa -dhw:M1010LT -r44100 -p512 -n8
sync I think is the same as "-S" and I think this is what would be causing it to go 16-bit

perusing strings against jackd, shows this parameter to be the same as -S,
the manpage that I see here does not mention --sync, but it mentions -S ...
strings `which jackd` output,
[ --sync OR -S ]

I don't know if it is has always been like this, but maybe you want to look at other things to get better quality for your sampling..
mevla wrote: Fri Aug 16, 2019 11:06 pm

Code: Select all

/usr/bin/jackd --sync -P80 -ndefault -dalsa -dhw:M1010LT -r44100 -p256 -n4 
If you want to make quality use of the capability of this card, I looked at the specs and it is supposed to be 96khz, so maybe you want to use something like,

jackd -R -P95 -dalsa -Dhw:M1010LT -r96000 -p 2048 -n2
(don't use -R -P99, that's at the priority level migration_task runs)

-R is for realtime..
(Make sure you have set your /etc/security/limits.conf to have the audio group of users capable of doing realtime, and have installed the rtkit-daemon service ...(package "rtkit") -- unless of course you have other ways of it starting up realtime)

fwiw, yes.. thanks for reminding me about pulseaudio-mess startups ;-) ... I know that I can plug jackd to work with pulseaudio's auto plugins, but when I'm fiddling with jackd, it is far easier that I manage the startup manually while I try to determine issues.

If you want to manually startup jack manually like I do here there's these little simple workaround scripts of one or two lines..

I don't want to bother with alsa and pulseaudio settings, so I tell pulseaudio not to load jack on startup..
load-module module-jackdbus-detect channels=2
comment out: load-module module-jack-sink channels=2
comment out:load-module module-jack-source channels=2

I use the "pacmd" in my source script to redirect pa's sink to "null", then onto "jackd" after jackd has started.. Pulseaudio is never stopped, it only has a changed sink(hardware audio cards are called "sink" for "final destination")

This essentially allows me not to tinker that much with commands, because I just have to hit the qjackctl's front-end interface with "start" and be done with it.
( if I need to modify the jackd command line I easily can change things and never worry that pulseaudio has to stop or be restarted, because essentially all that is needed it to use pacmd and redirect the sink)

So basically the pulseaudio daemon,
- goes to the null sink while jackd takes over to connect to the alsa driver,
- after jackd is fully started up, pulseaudio gets its sink to "jack_out"
- Upon shutdown, pulseaudio connects back to alsa...

If anyone wants to use these as a way to debug jackd/midi (to start jackd manually), they can try these workarounds...The scripts are short and do not need a "#!/bin/bash" header, each script is 1 or 2 lines and is relatively simple.

"
jack_start.source:
pactl set-default-sink null
/bin/sleep 2

jack_afterstart.source:
pactl load-module module-jack-sink channels=2
pactl set-default-sink jack_out
/usr/bin/a2jmidid -e &

jack_afterstart_bitwig.source:
pactl load-module module-jack-sink channels=2
pactl set-default-sink jack_out

jack_shutdown.source:
pactl unload-module module-jack-sink
#upon closing jackd, a2jmidid automatically closes

jack_aftershutdown.source:
pactl set-default-sink alsa_output.pci-0000_01_00.1.hdmi-stereo-extra1
pactl set-card-profile alsa_card.pci-0000_01_00.1 output:hdmi-stereo-extra1
"

(Note: the hardware alsa-driver named sinks above are particular for my case, to get the name of your alsa sinks, you can get them by using "pactl list-sinks". use the "name:" field , and exclude "<" ">" from the name)

If I ever need to use something outside Bitwig that needs to use my midi keyboard, I just stop jackd with qjackctl, rename jack_afterstart.source to jack_afterstart_bitwig.source, and merely click the start or stop buttons with qjackctl..

^ That's simple too! :p

my jackd/qjackctl setup I use -n4 which is kind of high for latency, but I don't have very exotic hardware connecting this midi keyboard.. but I do get good results regardless and so far works relatively well.

If you have the hardware, that's good but make sure you don't under-utilize it ;-) You paid for the 96khz, then set it to 96.. :)

thanks for your input, and I provide these qjackctl snapshots in case anyone else is wondering on how to use these workarounds. :)

..
fwiw, bitwig staff told/pointed me to a Q&A thread about using Virmidi. I looked into this and thank them for suggesting it, but it does not fix things. It only works random like 1 in 10 times, despite having disabled "auto-detect/adding" midi devices in bitwig's settings. Bitwig eventually grabs beyond the Virmidi device(even having Virmidi alone in the settings) and prevents another jackd client from mapping the same midi source, it's kind of going in circles at that point, and so the best solution for me is to start/stop jackd independently. It could be better if Bitwig builds their app to be more jackd-midi compliant, but the two are fighting for the same midi device... so essentially Jackd needs to be set not to use "-X", otherwise bitwig and jackd would be fighting to use it..

Bitwig developers need to fix this!!! The VirMidi solution on their Q&A does not work on every instance and is rather flakey as well -- it lists "Virmidi 16 devices" when there's actually "just one"

/etc/modprobe.d/my_sndvirmidi.conf options snd_virmidi midi_devs=1
aplaymidi -l
"28:0 Virtual Raw MIDI 3-0 VirMIDI 3-0"

It's not much more for me to explain, but I'm guessing this could be a reason why many Linux users are not adopting Bitwig, if the application is supposed to see just "one Virmidi" device and instead lists "16" and h-o-g-s beyond just Virmidi devices... then that tells me something..

Bitwig/Linux users need to know this... the alternative is to change the audio engine setting in Bitwig, but I do not want to meddle around alsa/pulseaudio settings.. Bitwig should "just work", but it doesn't, it even blindly would call jackd with "-Xseq" if you last ran jackd with it, utterly breaking Midi-detection ..

hopefully this gets fixed at some point

thanks.
You do not have the required permissions to view the files attached to this post.
Last edited by mwstl on Sun Aug 18, 2019 6:17 pm, edited 1 time in total.

Post

___ I merged my response above due to false-positive from KVRaudio's post-type detection ___
Last edited by mwstl on Sun Aug 18, 2019 6:21 pm, edited 2 times in total.

Post

___ I merged my response above due to false-positive from KVRaudio's post-type detection ___
Last edited by mwstl on Sun Aug 18, 2019 6:21 pm, edited 2 times in total.

Post

___ I merged my response above due to false-positive from KVRaudio's post-type detection ___
Last edited by mwstl on Sun Aug 18, 2019 6:21 pm, edited 2 times in total.

Post

___ I merged my response above due to false-positive from KVRaudio's post-type detection ___
Last edited by mwstl on Sun Aug 18, 2019 6:20 pm, edited 2 times in total.

Post

___ I merged my response above due to false-positive from KVRaudio's post-type detection ___

Post

mwstl wrote: Sun Aug 18, 2019 5:58 pm thanks mevla but I noticed a thing or two with your setup... I'm not super pro, but I noticed that your hardware is able to do 96khz and you're actually downgrading your sampling to 16-bit when it could be higher...
I never really looked into that. I have done yesterday the 657th sketch in 3 years, have a bunch of pieces on soundcloud, some in the signature below, have taken mixing lessons, and still learning. I'm certainly using 44.1Khz for sampling rate as the -r option shows. I have tried others but went back to 44.1KHz.

No-one so far has specifically mentioned that my pieces are lacking audio quality due to the sampling rate just by listening to them. A recent one, "3 Peaks" was remixed in a small pro studio in England and again the sampling rate was not mentioned.

So I take your comment with a grain of salt.

I'm not saying that I will never change those settings. What I'm saying is that there are more important things to focus on, like creating music and in order to do so, get a simple working system that works easily.

The screenshots you posted raises a question though. Since the approx. 20 years that I'm working with Linux I know that all configuration finds itself in a text file. The question being: where would all those nice settings find themselves for jackd to start with them, eg. in which file.

~/.config/jack/ is empty. .jackdrc only contains what was shown previously.

Doing a quick grep-find shows that the settings are stored in:

~/.config/rncbc.org/QjackCtl.conf

So then, when exactly are any of these pulled in when jackdrc is started from the command line, from .jackdrc as part of pulse audio, and NOT from qjackctl ?

I certainly want to keep an 'integrated system', one that jackd starts at boot and one that allows at the same time playing any media with audio instantly w/o having to adjust/start something each time. Which is the case now.

Post

@mevla, I've been using linux for quite some time as well, and I know most users do not want to bother setting up jackd, because it is not always plug&play. The fact that a developer told me the Khz works best when it is set at the capability of your "hardware driver" (this being alsa), works most effectively, otherwise jackd/alsa has to do more work doing conversion..

Qjackctl is a front-end to the jackd command. If Bitwig modifies ~/.jackdrc because you launched Bitwig to start jackd, then close Bitwig, little worry-> afaict qjackctl ignores ~/.jackdrc and uses the settings from QjactkCtl.conf

Code: Select all

"So I take your comment with a grain of salt."
You're the one who was pointing out "--sync" so I have to call you out on it. If you want to give me a suggestion, sure, I would take it, but "--sync" tbh is something that is only going to downgrade my audio and I don't think that's good for anybody... Your hardware is an i5 processor capable of doing much better imho than the setting you currently have so I gave you my insight..

fwiw "--sync" is not in the manpage, but it does the same thing as "-S" , you probably know that but other users who could be trying your suggestion do not know that may be downgrading the quality of their sampling..

Post

mwstl wrote: Sun Aug 18, 2019 7:30 pm @mevla, I've been using linux for quite some time as well, and I know most users do not want to bother setting up jackd, because it is not always plug&play.
I wouldn't know. Linux is my bread and butter for software development. So I'm not a typical user perhaps ... except when it comes to creating music at which point I like to sit in the seat of a user and just have everything ready to go with minimal, but essential, configuration.
mwstl wrote: Sun Aug 18, 2019 7:30 pmYou're the one who was pointing out "--sync" so I have to call you out on it.
I understand your point of view, although I did not specifically pointed out the '--sync' option as I'm using the same jackd command copy/pasted from quite some time ago.

However, I did find a reference to --sync which is probably where I got it from, from falkTX of KXStudio in 2015:

Quoted from Linux Musicians, June 2015:

"There's sync and async mode. async mode is the default. The option, provided by jack2 only, is to wherever or not to enable sync mode, instead of async.

async mode uses an additional audio buffer so that unresponsive apps don't make the audio stop. you could have a really bad app that causes 30xruns per second and the sound will still be flowing like there was no issue. this is because in async mode clients render audio into this new additional buffer, which is copied to the real hardware one at the end of the cycle. if some client didn't make in time (ie, xrun) jack2 will not copy that buffer. it's still possible to hear the xruns/crackles if some apps do very stupid things, but it's not common.

sync mode doesn't use this additional buffer, so the software-to-hardware latency is lower. but this means if some app misbehaves and causes xruns, you will hear crackles in the audio (always). note that jack1 doesn't have async mode."

End of quote.

Based on this, it made sense that I have preferred to have xruns when a plugin experiences difficulties and at the same time getting a better latency response. Especially in those times when I ran not a such 'powerful' computer: extra buffers for an asynchronous operation seemed not something I'd want.

Post

xruns == BAD. If -S is taking effect, then your system is taking in frames at 16-bit... you're preventing xruns by having less audio data sent to the card. That's my understanding of using this parameter but is not without a cost.

Post

mwstl wrote: Mon Aug 19, 2019 1:08 am xruns == BAD.
Look, (or hear), who wants to have xruns heard in their productions ?

Tagging them with "BAD" does not change anything.

I prefer to hear them as soon as something not right is happening, and at the same time have better latency responses, than running async and having problems with a plugin that will not surface up because of asynchronous operation.
mwstl wrote: Mon Aug 19, 2019 1:08 amIf -S is taking effect, then your system is taking in frames at 16-bit... you're preventing xruns by having less audio data sent to the card. That's my understanding of using this parameter but is not without a cost.
You did not seem to understand the previous explanation from FalxTX (KXStudio) about the sync option.

So here's one from today, Giso Grimm, Ardour mailing list:

"with --sync, jack2 behaves the same way as jack1 in the way of
scheduling the clients (no parallel graphs, but one block less
processing delay).

The --sync is important when extreme low delay processing matters -
without the flag, jack2 uses three buffers even when set to two.

This was recently discussed on the jack-dev list ("What about the number
of buffers?")."

Post

Xruns can be overruns or underrruns.. I don't want to add fruit to mal-advice, but according still to the developers is that the number of bits per frame is reduced.

Yes, there is explanation that "scheduling" (CFS - in the Linux kernel) -- something that I have tweaked on my end, and that is something you can do to reduce xruns... but from what is explained(from the manual itself), is the "bits per frame" is reduced << meaning the quality is reduced.

Sure anyone can use a reduction in data rates, and logically that would "lower" latency as it is less a burden on the hardware but at "what cost" ?

The scheduler is the "same", and why should it be any different? The scheduler is part of the Linux kernel, and not jackd. Xruns is something of a delivery notification by the Kernel/driver project for the option CONFIG_SND_DEBUG -- https://www.kernel.org/doc/html/latest/ ... cfile.html

But xruns -> are to be avoided at all cost... You should be checking whether you have overruns or underruns than assuming jackd is taking charge of scheduling. Listening to "pops" does not tell you whether you have underruns/overruns, you'd have to peruse the kernel stats for that.

Locked

Return to “Bitwig”