Cannot start jack as regular user

I know jack works because I can start it by running qjackctl as root. So I somehow need to give permission to something, somewhere, so my regular user can start jack.

This is the command that works as root:

/usr/bin/jackd -dfirewire -r48000 -p1024 -n3

But as a regular user, I get:

jackdmp 1.9.6 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2009 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 libffado 2.999.0- built Apr 5 2010 07:38:41 00730979233: Error (PosixThread.cpp)[ 150] Start: Cannot create realtime thread (1: Operation not permitted) 00730979343: Error (PosixThread.cpp)[ 151] Start: priority: 15 firewire ERR: FFADO: Error creating virtual device Cannot attach audio driver JackServer::Open() failed with -1 no message buffer overruns Failed to start server

I’ve done all the required stuff. I’ve set up limits.conf, my regular user is part of the audio group, I’m using an rt-patched kernel, etc. I haven’t been able to figure out what I’m missing so I can get going with Ardour and jack.

This might be of some help, there’s a thread on the AV linux forum about firewire cards:

Specifically, this might be related to the issues you are seeing - taken from the thread:

“1. Absolutely necessary:
Add your username to the ‘disk’ group. You can easily do this through the ‘User Setup’ tab of the Remastersys control panel. This will give you the proper permissions to use a firewire device. This is not set by default for security reasons. raw1394 devices have root access, so be sensible about who you allow to plug what into your firewire port if you do this.”

NOTE: You may have to use a different method to change the permissions since the Remastersys control panel is a part of the AV linux distro.

Thanks for the link and the tip. I followed that advice but it made no difference. I’ll go back over that page and peruse it closely in a bit. I think, though, that I need to still do something to give my regular user permission. Maybe a udev rules file somewhere?

I’m getting pretty close to just logging in as root. I know, I know, you’re not “supposed to”, but I’m a pragmatist and I do what works. This isn’t a machine I’m concerned will be blown to bits by a passing cracker. :stuck_out_tongue:

It shouldn’t be necessary to run as root, there’s obviously something odd going on. Can you start jack as a normal user if you use another interface other than firewire e.g. your onboard sound or if you use a dummy interface (I’m using jack not jackdmp, so I’m assuming you can do this with jackdmp e.g.)

jackd -R -p128 -d dummy

Also, I know this is perhaps a stupid question, but did you log out and back in again after adding yourself to the audio group etc? I normally do a complete restart after I’ve modified the /etc/security/limits.conf stuff just to be sure.

Adding myself to the audio group and modifying limits.conf happened many reboots ago. :wink:

I can start jack with libfreebob. The only problem is, libffado works better and has produced no xruns for me (that’s running qjackctl as root), whereas using the freebob driver produces lots of xruns when I leave it running for a while.

So I know it works. I’m just missing some odd file or touch somewhere to get my user to access libffado.

Seems like I’ve reached STUMPEM status! :stuck_out_tongue:

Guess I’ll be making root my regular user.

Make sure you configure your /etc/security/limits.conf properly, then make sure your username belongs to audio, users, wheel groups.
make sure no sounds or stuff like that are enabled (less servers running the more buffer you have and less latency) make sure your kernel supports realtime and then restart your system, them run qjackctl and configure your soundcard from there

good luck

you’re probably missing some audio group read/write permission on some firewire device. Might be a udev rule issue with firewire.

Depending on your version of udev, you may fix it by modifying




look for a sentence that goes like

KERNEL=="raw1394", GROUP="disk"

replace “disk” by “audio” and reboot. See if that helps.

For the record, I don’t see a -R switch to get jack running in realtime there, which I might guess could make a difference since the probem seems to be with the FFADO backend creating a realtime thread, which depending on who exactly it is doing this, this could make a difference I suppose.

Kind of a shot in the dark there though as I haven’t used FFADO.


I have used ffado regularly on several computers to connect my PreSonus FireStudio 26x26.
I recently installed from new with Fluxbox for the first time. I really like Flux, but i got sloppy about using sudo as I downloaded and compiled ffado, jack2 and ardour2.
I used sudo when not needed and in some folders, got ownership assigned to root, not me.
I’ve tried correcting permissions and ownership manually, but still jackd -dfirewire… only works with sudo, but will run with dummy without sudo.

How do I find what i’ve missed correcting?

Do I need to re-install everything, or is this correctable??


Has there been any further developments on this?

I’m seeing this problem with the latest -rt kernel on Fedora 14 and it looks like something in libffado fails to inherit the permissions to start a realtime thread. I know that I as a user can start a realtime thread (chrt -f 1 bash works just fine and a quick look at bash shows it running as SCHED_FIFO priority 1), so that’s not it.

I’ve added groups to my account until my fingers were tired of typing (williams disk wheel video audio users rtkit pulse-access pulse jackuser).

I’ve got udev rules to set permissions on the raw1394 device (I was trying the old stack with freebob too).

I’ve also added the /etc/security/limits.d stuff to setup rt permissions for jackuser group.

I’m guessing I may have to strace this and see if I can figure out when some thread changes it’s uid (which is the only way I can think of where a thread would not inherit the permissions to be able to call sched_setscheduler() from the parent thread.

Well, I did execute “strace /usr/bin/jackd -v -P20 -dfirewire -r48000 -p1024 -n3 -I4 -O4” and much to my surprise I found the following line in the output:

sched_setscheduler(2741, SCHED_FIFO, { 25 }) = -1 EPERM (Operation not permitted)

I’m not sure where the “25” comes from, but I’m guessing that it’s the sched_priority. Going on this guess, I modified my “/etc/security/limits.d/99-jack.conf” file such that the rtprio was greater than 25:

@jackuser - rtprio 30

And it worked. Thanks for the hint.