Rt jack priority one user, two priorites

Hi, folks. At the core, this is probably a Ubuntu-Studio 20.04 problem, but since I’m trying to get Ardour running this forum seems like a good place to ask. Especially building from this very useful thread: Anyone encountering RT Jack issues after upgrading to Ubuntu 20.04 LTS?

I have a fresh install of Ubuntu Studio as of December 2020:

mark@DAW:~$ uname -a
Linux DAW 5.8.0-33-lowlatency #36-Ubuntu SMP PREEMPT Wed Dec 9 10:08:12 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

The goal is to use Ardour to do recordings from DATs and cassette decks via an old MAudio PCI audio card, which I’ve done in the past. This doesn’t require a lot of interaction, so the machine can run headless with remote access through VNC or RDP. At least, that’s what I did in the past.

The new system runs fine, but qjackctl won’t start jack. The precise errors are probably not important at this stage. A major problem is that jack can’t run with realtime priority. This is a mystery because I am a member of the audio group:

mark@DAW:~$ cat /etc/group | grep audio
audio:x:29:pulse,mark

… and …

mark@DAW:~$ cat /etc/security/limits.d/audio.conf

@audio - rtprio 95
@audio - memlock unlimited

HERE’S THE PART THAT I DON’T UNDERSTAND:

I’m connecting to the KDE desktop through a Windows machine using RDP. I log in as ‘mark’. In that session, if I run jackd -dalsa -dhw:1 in a konsole terminal I get an error like this:

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

Them, if I try this (see thread above), note that my RT priority seems to be 0:

mark@DAW:~$ whoami ; ulimit -r ; chrt -f 80 echo “Yes RT”
mark
0
chrt: failed to set pid 0’s policy: Operation not permitted

IF, HOWEVER, I SSH into the box the result is different. jackd -dalsa -dhw:1 says “unable to connect to the forwarded X server” which makes sense since there isn’t one to connect to, but there are no realtime errors. And then:

mark@DAW:~$ whoami ; ulimit -r ; chrt -f 80 echo “Yes RT”
mark
95
Yes RT

This I do not understand. Both sessions seem to agree that I am who I am.

mark@DAW:~$ id -u mark
1000

My wife says so, too. So why does the KDE desktop session user have no RT priority? I do not see any conflicts in /etc/security:

root@DAW:/etc/security# grep -R audio
limits.d/audio.conf:@audio - rtprio 95
limits.d/audio.conf:@audio - memlock unlimited
limits.d/audio.conf:#@audio - nice -19

root@DAW:/etc/security# grep -R mark
root@DAW:/etc/security#

Does anyone have any ideas? Thanks so much!

Have you logged out and back in after making the changes to limits.d/audio.conf?

I didn’t make any changes to limits.d/audio.conf. Ubuntu-Studio seems to set it up OK out of the gate. I have certainly rebooted at least once since I started investigating. Thanks.

After some more experimentation, this seems to be a complete train wreck. Using X2go for remote desktop, I get to my desktop and ulimit -r does =95. Using Windows (Xrdb? as the server) my desktop starts with an empty konsole shell and ulimit = 0. Same for VNC using Xrfb as the server.

Even if I get a shell, qjackctl won’t start Jack properly, and neither will Ardour. Jack will run from the command line, but it looks like Jack can’t connect to Southbridge bus and Ardour can’t communicate with the selected sound card, either, using Alsa (or Jack) as the back end. No meaningful error messages from it or qjackctl and enough is enough. I fired up an old Win10 PC and popped by Delta Audiophile in it, installed the drivers, and it just works. Problem solved.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.