HowTO: Firewire audio on AVLinux

[trulan]

Updated 6-14-2011

Part one:  Firewire audio on AVLinux 4.2/AVLinux 5.0 with the JuJu firewire driver stack.

1a. AVLinux 5.0 users only:  Disable transparent hugepage support.
As root, edit /etc/default/grub and add

Code:

transparent_hugepage=never

to the GRUB_CMDLINE_LINUX_DEFAULT line.
Then, run (as root)

Code:

update-grub

...and reboot.

AVLinux 5 users will also want to set CPU frequency scaling to 'performance' by right-clicking the CPU scaling applet in the system tray.  To boot with the CPU governor set to performance, edit /usr/share/trayfreq/trayfreq.config.

1. Boot up your computer, then turn on and plug in your firewire device(s).

2. Start Jack Control (qjackctl) and enter these settings:
Driver: firewire
Priority: 70
Frames/Period: 64
Sample Rate: 44100
Periods/Buffer: 3
Timeout (msec): 2000

The rest of the settings can be left at their defaults.

(These settings should yield about 10ms actual round trip latency, which is generally considered negligible.  It is possible to run some devices at even lower latencies, but doing so will greatly increase CPU usage, and isn't officially supported anyway.)
If you want to use a higher sampling rate, it is a good idea to increase the Frames/period setting, as a higher sampling rate will lower latency and increase CPU load.  If you set your sampling rate to 96000, set Frames/Period to 128 and you should still have round trip latencies of just under 10ms.

3. Click 'OK' to save your settings, then click 'start' to start the Jack audio server.  In a second or two, your devices should sync up.  Fire up the LinuxDSP Jack Patchbay and you should see all the available inputs and outputs.  Here's a screenshot of the patchbay with two PreSonus Firepods connected:


4. Finally, start up your favorite Jack-aware application and you should be happily on your way!

----------------------------------------------------------------------------------------------


Part two:  Firewire audio on AVLinux with a realtime kernel and the legacy firewire drivers.
Some devices are not yet functional on the new firewire stack, and some hardware configurations will not perform well without a realtime kernel.  If you are having performance issues, or if you just prefer things the way they used to be, here's how you can get it all set up:

1. Install a realtime kernel:
2.6.33.7.2-rt30 is the latest realtime kernel and is a good choice unless you need the nvidia binary drivers.
2.6.31.12-rt21 is a rock-solid kernel and will work with the nvidia drivers.
You can find the kernels here:  http://www.remastersys.com/forums/index.php?topic=1243.0
Unzip the kernel files, then install them using gdebi.  Install the kernel image first, then the headers.

2. Add 'libraw1394' to /etc/modules:
As root, edit /etc/modules and add

Code:

libraw1394

to a new line, somewhere above 'loop'.  Then save and close the file.

3. 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 your user the ability to access the raw1394 device node, which requires root access.  This comes with the obligatory 'security risk' warning.
**Note:  this is defined by the presence of the following line, in /lib/udev/rules.d/91-permissions.rules:

Code:

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

This should already be there in any AVLinux installation.

4. Prioritize IRQ's:
(IRQ threading is the reason we use the RT kernel in the first place, so we might as well take advantage of it.)
As root, edit /etc/default/rtirq

The line we are interested in is RTIRQ_NAME_LIST. By default it reads:

Code:

RTIRQ_NAME_LIST="rtc snd usb i8042"

Add ohci1394 second in the list, so it looks like this:

Code:

RTIRQ_NAME_LIST="rtc ohci1394 snd usb i8042"

If you're using a laptop with PC-Card firewire controller, where a card controller is involved, the card controller's device name (usually 'yenta') should be before ohci1394 in the list.

Code:

RTIRQ_NAME_LIST="rtc yenta ohci1394 snd usb i8042"

Then save and exit.
(For a more detailed explanation, and for more IRQ tweaks, read this very informative page:
http://subversion.ffado.org/wiki/IrqPriorities)

6. Reboot:
At this point, all settings should be in place.  With your firewire device(s) plugged in and turned on, reboot into the realtime kernel.  (While rebooting with the firewire stuff plugged in sometimes causes issues when using the Juju firewire stack, it works better to have them connected when using the legacy driver stack, especially if you have several devices daisy-chained.)

7. You're ready to get Jack set up and running.  For help on that, return to part one of the guide, step 2.

(Note: the AVLinux kernels are compiled with only one firewire driver stack in place.  So, no module blacklisting is necessary - you can switch between the Juju firewire stack and the legacy driver stack by simply rebooting into a different kernel.  The Liquorix-based kernels only include the Juju stack, while the RT kernels only include the legacy stack.)

8. (Optional - may help but it's hard to tell...) Prioritize the tasklet threads - the bottom half of your IRQ handlers.
(must be run as root)

Code:

ps -eLo pid,cmd | grep tasklet| awk '{ system("chrt -f -p 78 " $1)}'

It sets their priority to 78.
* You can choose another number if you like - it should be less than the firewire controller's priority, but higher than your Jack priority setting.  78 is a good number if you have set rtirq as described above.  I find it works well to put that command in /etc/rc.local, so it is run on bootup.

----------------------------------------------------------------------------------------------


Troubleshooting:
A good place to start is the command 'ffado-test ListDevices'.  It should output something like this:

Code:

trulan@AVLinux:~$ ffado-test ListDevices
-----------------------------------------------
FFADO test and diagnostic utility
Part of the FFADO project -- www.ffado.org
Version: 2.999.0-
(C) 2008, Daniel Wagner, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.
-----------------------------------------------

=== 1394 PORT 0 ===
  Node id  GUID                  VendorId     ModelId   Vendor - Model
   0       0x000a9200c6121078  0x00000A92  0x00010066   Presonus  - PreSonus FIREPOD
   1       0x000a9200c5112047  0x00000A92  0x00010066   Presonus  - PreSonus FIREPOD
02553417864: Error (configrom.cpp)[ 150] initialize: Could not parse config rom of node 2 on port 0
no message buffer overruns

This will show any connected firewire devices.  The 'config rom' error is normal.

For more information, run 'ffado-diag'.  Please include the output of this command when asking for help.

[GMaq]

trulan,

Great HowTO addition! Thanks very much for sharing it.

[mrufino1]

That file doesn't exist on my system, it did on ubuntu when I followed your guide. Any ideas as to why that might be? Also, what is the command again in the terminal to list the devices so I can see the name of my firewire card? Thanks.

[trulan]

Code:

lspci

will show a whole bunch of stuff, to see just the firewire card run

Code:

lspci |grep 1394

The rtirq script was not in the 3.0 and 3.0r1 testing iso's, but is included in 3.0r1 final.  You need two files:  the script (/etc/init.d/rtirq) and the configuration file (/etc/default/rtirq).

If you have 3.0 or 3.0r1 testing installed and want to use rtirq, it's not too difficult, just a few commands to run.  This may not be the best way to install it but it worked for me.

 - download from here: http://www.rncbc.org/jack/#rtirq
 - extract and put the files in their correct locations:
   # cp rtirq.sh /etc/init.d/rtirq
   # cp rtirq.conf /etc/default/rtirq
 - make rtirq executable (may not be necessary):
   # chmod 755 /etc/init.d/rtirq
 - add ohci1394 to names and non-threaded lists in /etc/default/rtirq
 - make it run at startup (add the following line to /etc/rc.local - there may be a better way to do this)
   /etc/init.d/rtirq start

[mrufino1]

This seems to have made things worse, much worse.
When I did lspci, this is what came up for firewire
16:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)

What from that line should I be including in the script modicifation? The script is installed and I followed your directions, added ohci1394 to where it needed to be.
RTIRQ_NAME_LIST="rtc Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) ohci1394 snd usb i8042" Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)

Should it look like this?
 
Once I removed the bit Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) it is running better, but I am still getting xruns that are either making ardour disconnect or quit entirely. I looped a section and let it play for a while, which worked without xruns for a while but then they are coming back. And I notice if I click the playhead manually to skip to a spot, jack immediately disconnects.

Any ideas? This is pretty frustrating, but I am determined to get it, there has to be something simple, not just with this script but in general. Oh, and the last script you indicate, the one with the priority at 78, was disastrous on this system, jack bombed over and over.
So, not sure where I am going from here, and adivce is helpful and thanks for your help so far.

[trulan]

The rtirq script uses grep to find your devices and prioritize them accordingly.  So it's easy to give it too much information.  You should have a one-word name in the list for each device you are prioritizing.  Every space is viewed as a separator, denoting another device.

Can you post the output of

Code:

cat /proc/interrupts

and

Code:

ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq"

Also, what do you have Jack Control's real-time priority set to?  (default, 70, 75, etc)?

[mrufino1]

Output of cat /proc/interrupts

Code:

          CPU0       CPU1       
  0:   35232525         24   IO-APIC-edge      timer
  1:       2676          0   IO-APIC-edge      i8042
  8:        130          0   IO-APIC-edge      rtc0
  9:      67659          0   IO-APIC-fasteoi   acpi
 12:     102252          4   IO-APIC-edge      i8042
 14:      55106         18   IO-APIC-edge      ata_piix
 15:      15971          0   IO-APIC-edge      ata_piix
 16:   57483220          9   IO-APIC-fasteoi   uhci_hcd:usb2, yenta, ohci1394
 17:      10557          0   IO-APIC-fasteoi   uhci_hcd:usb3, HDA Intel
 18:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 19:     239021          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb5
 29:      44094          0   PCI-MSI-edge      eth0
 30:    1244454          0   PCI-MSI-edge      iwl3945
NMI:          0          0   Non-maskable interrupts
LOC:   12565610   27406601   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:          0          0   Performance monitoring interrupts
PND:          0          0   Performance pending work
RES:    3902483   33186814   Rescheduling interrupts
CAL:        491        235   Function call interrupts
TLB:       5839       5605   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:        187        187   Machine check polls
ERR:          0
MIS:          0

and output of ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq"

Code:

    4  TS      -  19   0 [ksoftirqd/0]
    7  TS      -  19   0 [ksoftirqd/1]
12354  TS      -  -1   0 grep -i irq

However, (please don't prove me wrong ardour and jack!!!), I played with some jack settings and some ardour settings (shut off denormal handling, shut off MMC, check use OSC- don't know if any of those make a difference- and in Jack I unchecked "no memory lock"), and I also got ride of the udev rules file I made, and I have had jack running for about 15 hours, only xrun I got was just a few minutes ago when like a dummy I tried to adjust the clock settings (as in time of day clock, not audio clock) and locked up the system (ardour was playing back). I think something was very messed up in the session I was running, so I reimported the files to a new session and it has been much more stable. In fact, I left my song playing in a loop overnight, from 1am-10am, and it was still running with no xruns, so that's a good sign.
I did have a weird crashing bug wiht ardour- this is STRANGE. I had a track called 03-tom , and that seemed ot cause all sorts of problems, from ardour quitting spontaneously when naming the track, to finding that track disconnecting randomly from jack, causing xruns, and making ardour disconnect (in the jack messages it seemed to indicate this). I renamed it to 03-floor and have not had a problem since. Strange. But it seems to be true. I will file that in a bug report for ardour, already filed one related to the invada early reflection reverb and the send channel.

trulan, I appreciate your help so far, I'm getting through this and am definitely finding the ins and outs (pardon the pun) of ardour and jack as I work. Productivity soon!

[trulan]

Glad it's working for you!  The "no memory lock" setting sounds like the most likely candidate to me, but that's just my guess.

One more change I would make - I see "yenta" in this line:

16:   57483220          9   IO-APIC-fasteoi   uhci_hcd:usb2, yenta, ohci1394

and if I understand the ffado wiki page (linked above) that would be your pc-card controller.  So your RTIRQ_NAME_LIST should look like this:

Code:

RTIRQ_NAME_LIST="rtc yenta ohci1394 snd usb i8042"

And since the list is getting kind of long, 5 is too big of a step so I would change it to 2, like this:

Code:

# Priority decrease step.
RTIRQ_PRIO_DECR=2

Both of those edits are in /etc/default/rtirq.  And your jack priority setting should then be 70 or 75, or in that neighborhood.

[mrufino1]

Hi Trulan, jack seems pretty solid now, I am still running at about 272 ms latency, but I am mixing right now, so it is on purpose. However, I cannot use the av realtime kernel- xrun city there. regular kernel seems like it is fine here though. What are your thoughts on that? I know Glen has talked about not really needing the rt kernel the way he has av set up. My issues with ardour crashing now seem to be coming to light and are not jack related I don't think, so that's good- I'm getting segementation faults (not sure what those are yet but I'll be googling!). Thanks for your help with all of this.

[trulan]

Well, it sounds like you're making progress.

To be honest I haven't played with the AVLinux desktop kernel a whole lot.  I did a bit of kernel comparing in Ubuntu and using RT made a huge difference there so I have stuck with it.  But then my computers are all at least three years old - a faster computer probably wouldn't benefit as much.

It seems odd to me that the RT kernel would cause more x-runs, you 'should' find the opposite to be true.  But reality is always more accurate than theory, and if it meets your needs, that is what matters.

[GMaq]

RE: Rt vs Desktop,

One thing to consider is that the rtirq script is not being called for the desktop kernel at bootup, so if mrufino is having better luck without the script then perhaps it is more hardware dependent and specific than I thought. On my own hardware the desktop Kernel gives amazingly variable results...a laptop with Intel HDA will happily run a keyboard setup all night long at gigs at 256fpp (11ms) with never an xrun and on my desktop my "Pro Audio" M-Audio 1010LT needs at least 1024fpp and will still xrun occasionally but it works fabulously with the -rt Kernel. My Tascam US-122 seems to perform equally well on both Kernels. All this really proves is that hardware and kernel are chuck full of variables and no 2 setups will behave alike... even firewire apparently.

As far as latency goes...it is misunderstood to some degree and becomes a gymnastic event sometimes. For instance if you are tracking in Ardour and are not running through a synth plugin or a Guitar Amp simulator on the way to the track latency doesn't matter really.  It only becomes important for piping in plugins or effects en route to the track, after that the issue becomes setting latency to prevent xruns and that's it. As far as Ardour if you are getting segfaults I'd really suggest filing a bug report at the Ardour site.

[trulan]

I've updated the guide to reflect changes in AVLinux 4.0, especially the switch to jack2.  I have not actually installed 4.0 myself at this point, so I want to make sure I have a few things still correct:
1. raw1394 permissions are still set to the 'disk' group.
2. AVLinux 4.0 now uses Jack2, or jackdmp.
3. The rtirq script is still installed by default.
If any of these assumptions are incorrect, please let me know.

[varpa]

I just got a Focusrite Saffire PRO 24 and it works more or less out-of-the-box on AVLinux 4.0 by virtue of the fact that AVLinux contains a recent SVN version of ffado.  This device is labelled "Experimental" by ffado because it only runs from one of the recent SVN versions and is still under active development.  I did have to update the firmware (on other
OS) and add raw1394 to /etc/modules (to automatically load raw1394 at boot).  After that it worked - already recorded a few test tracks on Ardour.  Thanks to GMaq for including a recent version of ffado in 4.0.

[damnit321]

tnx varpa!! .. this is what I was trying to say in my post regarding avioding xruns.. tuneing the rt kernel can be very benificial and is blatantly a needed thing certainly with firewire. I even managed to get my dsp load down from 100% to 22% some how with some obsesive tinkering..


i have 'top' customized for my RT enviroment so it shows all the RT process's first and highest cpu abusers and that is helpful to see what is strugling for cpu time.

which has me wondering if some one might be so bold to make a process and irq analyzer to monitor the systems sugested work load  and notes which prcocess's and irqs/modules tear up system resources so you can set them acordingly

I look forward to try the phase 24 firewire again that I have laying arround, I gave it a quick try before under 3.1 and hit problems straight away but I was assuming 3.1 was ready like 4.0, so i thought it was fubar or the HCI was the problem but I cant see it as its a confirmed working with a TI chip.

[bossesand]

I have noted that in the latest 20100706 you have to either start
modprobe raw1394  manually or add
 a line with raw1394 to /etc/modules to get auto start of the raw1394 which is needed.

I am in the process of assisting in adding a new interface to ffado
and at the moment we are in a strange state it almost work :-).

I have to check all the tips in this thread.
Seems to be usefull information here.

Thanks bosse

[GMaq]

Hi,

Are you saying that adding yourself to the 'disk' group is no longer sufficient? This is important for me to know because I personally don't have a firewire interface to test this stuff on, so if changes need to be made I will do it but I need to know what exact changes are required.

[bossesand]

Are talking to mee? 
Yes you have to start the raw1394 manually via modprobe raw1394 or add it to /etc/modules for auto start.

If I understand it correctly raw1394 is not needed in later versions of the kernel, or is it the firewire drivers?
but in the current/latest AVlinux it is still needed.

Best Regards
Bo-Erik

[trulan]

raw1394 is still needed in AVlinux.  It is possible to operate without it (ie, to use the new firewire stack) but not without some key changes:
1. A newer kernel - at least 2.6.32 (but 2.6.33 with the rt patch performs much better for me).  Kernel must be compiled with the new stack enabled in the kernel config, and the legacy firewire stack must be disabled in the config or blacklisted via modprobe.d.
2. libffado 2.0.1 (or newer)

And it works, indeed it works very well.  The device name changes from ohci1394 to firewire, so /etc/default/rtirq must be changed to reflect this.  CPU usage is noticeably lower, stability seems good, permissions settings are less troubling.

The only major problem (and the deal-breaker for me, the reason I'm still running the old stack) is that multiple devices (ie, daisychaining) is not yet supported on the new stack.  This is supposedly coming in kernel 2.6.36.

FWIW.

[Alex Kemp]

(2.6.31.12-rt21) 2. Add 'libraw1394' to /etc/modules:
As root, edit /etc/modules and add

Code:

libraw1394

to a new line, somewhere above 'loop'.  Then save and close the file.

That does NOT produce a /dev/raw1394 directory. To do so, the entry needs to be `raw1394' (not `libraw1394').

I derived the above initially from the entry within /etc/modules for AV4.1. Then, checking the alias file:

Code:

$ grep '1394' /lib/modules/2.6.31.12-rt21-avlinux-realtime-pae-rev4/modules.alias
alias pci:v*d*sv*sd*bc0Csc00i10* ohci1394
alias ieee1394:ven*mo*sp0000A02Dver00000102* video1394
alias ieee1394:ven*mo*sp0000A02Dver00000101* video1394
alias ieee1394:ven*mo*sp0000A02Dver00000100* video1394
alias ieee1394:ven*mo*sp0000A02Dver00000102* raw1394
alias ieee1394:ven*mo*sp0000A02Dver00000101* raw1394
alias ieee1394:ven*mo*sp0000A02Dver00000100* raw1394
alias ieee1394:ven*mo*sp0000A02Dver00010001* raw1394
alias ieee1394:ven*mo*sp0000609Ever00010483* sbp2
alias ieee1394:ven*mo*sp0000A02Dver00010001* dv1394
alias ieee1394:ven*mo*sp0000005Ever00000001* eth1394

It's very likely that I've mis-understood, as I only half-understand what's going on, and my camcorder still will not appear within kdenlive. Anyway, to the best of my understanding, you mis-spelt.

[3c273]

Excellent tutorial! Thanks for posting.

I just got a Focusrite Saffire PRO 24 and it works more or less out-of-the-box on AVLinux 4.0 by virtue of the fact that AVLinux contains a recent SVN version of ffado.  This device is labelled "Experimental" by ffado because it only runs from one of the recent SVN versions and is still under active development.  I did have to update the firmware (on other
OS) and add raw1394 to /etc/modules (to automatically load raw1394 at boot).  After that it worked - already recorded a few test tracks on Ardour.  Thanks to GMaq for including a recent version of ffado in 4.0.

How does it work with on AV Linux 5.0.1 and 5.0.2? I'm considering buying a new interface in that class. Thanks.

[joe k]

Im Trying to set up RT scheduling on my acer loptop which has a Firewire 4 pin built in to the machine
heres the output from lsmod
firewire_ohci          21530  0
firewire_core          34673  19 firewire_ohci
sdhci_pci               6065  0
sdhci                  15871  1 sdhci_pci
crc_itu_t               1015  1 firewire_core

and this is the rtirq list:
RTIRQ_NAME_LIST="rtc yenta firewire snd usb i8042"

What should the order be for the RTIRQ ?

I'm using the firewire to connect to a audio device and use it with jackd

THanks  jk

[trulan]

You don't need "yenta" in the list if you're using the built in 4-pin port, that's only necessary for some PC-card firewire controllers.  You could remove snd, usb, and i8042 from the list too if you wanted, but I usually leave them there.  When you're using an onboard firewire controller, the only two you need to worry about are rtc and firewire.