# [SOLVED-ISH] Firewire with jack, permissions issues

## miscsubbin

I hope this is in the right place, but I am trying to use a device (/dev/fw0, I believe) on firewire. I have it being set up by JACK with

```
jackd -R -d firewire
```

This works when run as root, but when I run it as a normal user I get this error:

```
matt@matt-PC ~ $ jackd -R --verbose -d firewire

jackd 0.121.3

Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.

jackd 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

getting driver descriptor from /usr/lib64/jack/jack_net.so

getting driver descriptor from /usr/lib64/jack/jack_firewire.so

getting driver descriptor from /usr/lib64/jack/jack_alsa_midi.so

getting driver descriptor from /usr/lib64/jack/jack_dummy.so

getting driver descriptor from /usr/lib64/jack/jack_alsa.so

JACK compiled with System V SHM support.

server `default' registered

registered builtin port type 32 bit float mono audio

registered builtin port type 8 bit raw midi

clock source = system clock via clock_gettime

loading driver ..

start poll on 3 fd's

new client: firewire_pcm, id = 1 type 1 @ 0x60a120 fd = -1

new buffer size 1024

resizing port buffer segment for type 0, one buffer = 4096 bytes

resizing port buffer segment for type 1, one buffer = 4096 bytes

libffado 2.1.0- built Oct 18 2012 11:51:06

cannot allocate memory for thread-local data: ABORT
```

It's clearly some kind of permissions issue, but I don't really know where to look. Can anyone help me out?Last edited by miscsubbin on Sun Nov 04, 2012 8:43 pm; edited 2 times in total

----------

## miscsubbin

Umm, maybe I should clarify?

I set up the following files from Googling (I really have no idea what they do, some help there would be appreciated):

/etc/security/limits.d/90-jack.conf

```
###  START FILE  ###

# Planet CCRMA, jack-audio-connection-kit

#

# Allow processes access to rt priority and memory locking

# without limits, needed by the rt kernel and jackd

*   -   rtprio   99

*   -   memlock   4194304

*   -   nice   -10

###  END FILE  ###

```

/etc/security/limits.d/40-realtime-base.conf (not sure if this one has been adjusted)

```
# Start of 40-realtime-base.conf from realtime-base-0.1

@realtime   -   rtprio   99

@realtime   -   memlock   unlimited

# End of 40-realtime-base.conf from realtime-base-0.1

```

etc/udev/rules.d/50-raw-firewire.rules

```
KERNEL=="raw1394", NAME="raw1394", GROUP="audio"

```

/etc/udev/rules.d/70-persistent-fw.rules

```
# firewire rule for raw1394 device permissions

KERNEL=="raw1394",NAME="%k",GROUP="audio"

```

So I really don't know what these do, but I created them after reading a bunch of things on Google, to no avail. Maybe something in them needs to be changed?

----------

## miscsubbin

If there's anything else I can post to help, just ask.

Is this in the wrong forum?

----------

## miscsubbin

Ok, I guess I'll have to take this somewhere else.

----------

## Navar

 *miscsubbin wrote:*   

> This works when run as root, but when I run it as a normal user I get this error:
> 
> [...]
> 
> It's clearly some kind of permissions issue, but I don't really know where to look. Can anyone help me out?
> ...

 

Have you checked if you are part of the audio group as a normal user?

----------

## miscsubbin

Yes I am.

```
matt@matt-PC ~ $ groups matt

disk wheel audio video usb plugdev games powercontrol matt

```

----------

## Navar

Perhaps the suggestions here?

----------

## tbart

same problem here, solved it right now with this

```
blackknight ~ # cat /etc/security/limits.d/audio.conf 

#<domain>      <type>  <item>         <value>

@audio          -       rtprio          99

@audio          -       memlock         unlimited
```

(that is, changed 500000 to unlimited)

you might also try adding your user to the realtime group, now that I see there is a preconfigured group for that.

if you get positive results by running

```
jackd -r -d firewire -n 3 -p 2048
```

that is, DISABLING the standard (-R) realtime feature, your problem lies within realtime permissions for your user. you don't need to change udev rules anymore, then. (they define what nodes/symlinks in /dev get created when a new device gets found, and their permissions. your setup looks good to me...)

check 

```
ulimit -a
```

 as a user to verify the above config files do apply. Remember you have to logout and login for changes to take effect.

PAM may be at fault, look for something like this if ulimit does not reflect the changes to your files.

```
blackknight ~ # grep -r pam_limits /etc/pam.d/*

/etc/pam.d/system-auth:session      required   pam_limits.so 

/etc/pam.d/system-services:session      required   pam_limits.so
```

(maybe you're using some alternate login manager...)

let me know how you're doing, I am doing my first tests with a Saffire 24 and I need it to work on 2nd of Nov ;->

----------

## miscsubbin

My Gentoo install was destroyed in a freak fdisk accident (along with my Windows install as well). I've installed Arch in it's place in order to try it out. I may move back eventually, but for now I've solved the same problem on Arch at the very least.

/etc/udev/rules.d/70-persistent-fw.rules

```

# firewire rule for raw1394 device permissions

KERNEL=="fw0",NAME="fw0",GROUP="audio" 
```

is the only udev rule I have and it seems to work.The difference is that I now use fw0 instead of raw1394. I didn't have raw1394, possibly because I have 2 firewire ports, or maybe raw1394 was deprecated and I didn't even know. Whatever, at least it works by some means.

----------

## tbart

interesting. my saffire is currently not here at my box, but I do have /dev/fw0 and I do not have raw1394. raw1394 seems to be from the old firewire stack, the new one does not seem to provide it.

however, if there's only /dev/fw0, I don't have to change permissions for it, as I do not have any rule saying so. so at least on this gentoo setup, I am able to work with the interface without any special udev rule whatsoever, it seems...

(some realtime scheduling improvement howtos say it might be wise to do the following:

```
KERNEL=="rtc", GROUP="audio", MODE="0660"

KERNEL=="hpet", GROUP="audio", MODE="0660"
```

I don't know whether it changes anything)

I successfully recorded 7 tracks 24bit/44100Hz for ~90mins without an xrun on my saffire. I used ecasound and ecasignalview as ardour was a little too instable when testing beforehand.

all the best!

th

(that's the/my band it should finally get used for...:

http://www.youtube.com/watch?v=K56GLPtUxxk)

----------

