Anyone encountering RT Jack issues after upgrading to Ubuntu 20.04 LTS?

Hey!
Before I upgraded Ubuntu to 20.04 LTS jack worked fine. After updating it seems that RT scheduling does not have in its plans to work. Anyone can help me? I could use ALSA instead but I’m translating ardour6 and I can’t use that option. Here’s my logs.

ardour6 says:

ERROR: JACK: Cannot create thread res = 1

Found nothing along /home/stefano/.config/ardour6/templates:/usr/local/share/ardour6/templates
JackTemporaryException : now quits...
Jack main caught signal 2
Released audio card Audio1
audio_reservation_finish

while jackd says:

Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns

I have already added my user to group audio:

stefano@stefanoASUS:~$ groups stefano
stefano : stefano adm disk cdrom sudo audio dip plugdev input lpadmin lxd sambashare docker

and also allowed RT and memory lock in /etc/security/limits.conf (and also /etc/security/limits.d/audio.conf):

stefano@stefanoASUS:~$ cat /etc/security/limits.conf | grep audio
@audio		-	rtprio		95
@audio		-	memlock	unlimited

It doesn’t either work to use root. What else could be the problem? Kernel stuff?

Did you remember to log out and in again after editing limits.conf?

Yes sir. I tried also to restart, just in case, but nothing. :frowning:

1 Like

That’s strange.
I booted the xubuntu 20.04 live USB, added the default xubuntu user to the audio group, added the limits.conf lines and logged out and in again.
Then I checked with ulimit -a , which said “real-time prio 95” and “max locked mem unlimited” as expected.

What does ulimit -r and ulimit -l say in your case?

It’s a long shot but maybe you should remove either the /etc/security/limits.d/audio.conf or the lines in limits.conf.

stefano@stefanoASUS:~$ ulimit -r
95
stefano@stefanoASUS:~$ ulimit -l
unlimited

I tried to remove one but nothing changes. I don’t know if it has any relevance, but I noticed that:

root@stefanoASUS:/home/stefano# ulimit -l
65536
root@stefanoASUS:/home/stefano# ulimit -r
0

You had ulimit -r = 95 before you did the change which set it back to zero, so if you undo that last change you have the right premises for running RT-enabled jack.

I could have not understood what you mean, but that output comes only with root user. If I use my user it is still 95/unlimited.

Yes, 95/unlimited is what we want.
That means that your stefano user can run real-time tasks at priority 95 and can lock unlimited RAM.

You should be able to start jack in a terminal window using something like
jackd -R -P 95 -d alsa -r 44100 -d hw:PCH,0

Still not working :frowning:

JACK server starting in realtime mode with priority 95
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:PCH,0|hw:PCH,0|1024|2|44100|0|0|nomon|swmeter|-|32bit
configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
Cannot use real-time scheduling (RR/95)(1: Operation not permitted)
AcquireSelfRealTime error

What does aplay -l say?

Sorry for italian translations, hope you understand what you need to know.

**** Lista di PLAYBACK dispositivi hardware ****
scheda 0: HDMI [HDA Intel HDMI], dispositivo 3: HDMI 0 [HDMI 0]
  Sottoperiferiche: 1/1
  Sottoperiferica #0: subdevice #0
scheda 0: HDMI [HDA Intel HDMI], dispositivo 7: HDMI 1 [HDMI 1]
  Sottoperiferiche: 1/1
  Sottoperiferica #0: subdevice #0
scheda 0: HDMI [HDA Intel HDMI], dispositivo 8: HDMI 2 [HDMI 2]
  Sottoperiferiche: 1/1
  Sottoperiferica #0: subdevice #0
scheda 0: HDMI [HDA Intel HDMI], dispositivo 9: HDMI 3 [HDMI 3]
  Sottoperiferiche: 1/1
  Sottoperiferica #0: subdevice #0
scheda 0: HDMI [HDA Intel HDMI], dispositivo 10: HDMI 4 [HDMI 4]
  Sottoperiferiche: 1/1
  Sottoperiferica #0: subdevice #0
scheda 1: PCH [HDA Intel PCH], dispositivo 0: ALC3236 Analog [ALC3236 Analog]
  Sottoperiferiche: 0/1
  Sottoperiferica #0: subdevice #0

I have Sottoperiferiche: 1/1 on my PCH card but I don’t think that matters.

Are you running the generic kernel or something else?
What does uname -a say?

Yes, it is a generic one.

stefano@stefanoASUS:~$ uname -a
Linux stefanoASUS 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Please run ulimit -r again and post the result.

Because the “Cannot use real-time scheduling (RR/95)(1: Operation not permitted)” error is what I get when I try to run jack at a higher level than I have permission to.
My ulimit -r says 95 and if I use -P 99 I get a (RR/99) error, which is as expected.

So it seems that the user you’re using to start jack does not have real-time = 95 permission.

That’s the mistery…

stefano@stefanoASUS:~$ ulimit -r
95

Run grep rtprio -R /etc/security/* and see if you have multiple rtprio entries competing with each other.
Like if your audio group has 95 but you have an entry for the stefano group, for example, which has something lower, and that ulimit for some reason chooses one and jack the other.

If that’s not the case then I’ve got no clue why it doesn’t work for you.

You could also try running the jackd command, start with -P 0 and then increase the value to see what jack thinks your max prio is.

I have the same. When you look at the Ubuntu Kernel changelog, you will find:

2020-04-20 - Andrea Righi andrea.righi@canonical.com linux (5.4.0-26.30) focal; urgency=medium 5.4.0-24.28 does not seem to apply rtprio, whereas -21 does. (LP: #1873315) - [Config] lowlatency: turn off RT_GROUP_SCHED *

That means with the current Generic Kernel rtprio cannot be set. Hope they will put it back into the next Kernel update.

Only solution is to switch Real Time off in Jack.

5.4.0-24 had the rtprio bug but both Stefano and myself are using the same, apparently corrected, 5.4.0-26 kernel build Apr 20 16:58:30

From the bug report: “This bug was fixed in the package linux - 5.4.0-26.30”

Thanks for that info. Checking
grep -e “CONFIG_IRQ_FORCED_THREADING=y” -e “CONFIG_PREEMPT=y” /boot/config-uname -r
gives me: CONFIG_IRQ_FORCED_THREADING=y

Also I added threadirq to the grub. It is not loaded.
Checking the Kernel config file in /boot, I cannot find these
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT=y

Could that be the issue?

Probably not.
The CONFIG_PREEMPT_RT seems to come from the RT patch, so if you’re running -generic you’re not supposed to have that line.
-generic has CONFIG_HZ=250

The thing is; I’m using the 20.04 Xubuntu Live USB, with the default 5.4.0-26-30-generic kernel, and I’m not having any problems running jack at rtprio 95.