The FirePod has been renamed to FP10:

More details on the FP10:

Support Status: 
Reported to work


The FirePod works here. In freebob-1.0.x and only-audio. Midi is somehow broken. Should get fixed ffado...

See my own blog for some details.

With libfreebob revision 439 both MIDI and Audio work, though occaisonally I have seen note-events go missing under higher system load.

Also sample rate changes or jack crashes require me to disconnect the 1394 bus either by powering off the firepod or unplugging it from the system.

The missing note events could occur when there is packet loss. Normally this doesn't happen on a well-configured system.

Changing the sample rate should not require you to unplug the device, this is a bug.

When jack crashes you indeed have to disconnect & reconnect the device. This is not a 'bug' but rather a 'flaw'.

I have upgraded to kernel- and libffado revision 471 and jackd rev 1040 and am seeing audio dropouts in the playback stream, the recording *seems* to be fine, I hear clicks in the recorded data in ardour, but I replay them and they are gone.

My system is a Athlon XP 2000+, so perhaps my system just sucks, though the specs for Windows with the firepod are well below this.

Below are my full system specs if they are useful:

dave@sonic ~/src/jack $ cat /proc/interrupts
0: 1463147455 XT-PIC-XT timer
1: 2 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
5: 214643200 XT-PIC-XT ohci1394
6: 5 XT-PIC-XT floppy
7: 28 XT-PIC-XT parport0
8: 2 XT-PIC-XT rtc
9: 21 XT-PIC-XT acpi
10: 5326477 XT-PIC-XT eth0
11: 14332540 XT-PIC-XT nvidia
12: 94811 XT-PIC-XT uhci_hcd:usb1, uhci_hcd:usb2, i8042, CMI8738-MC6
14: 144977 XT-PIC-XT ide0
15: 494952 XT-PIC-XT ide1
NMI: 0
ERR: 0

No interrupt clashes except CMIPCI sound card which is not being used.

MemTotal: 1294412 kB

Disks are 120 and 200GB LVM2, with Reiserfs.

There are no jack xruns and I am running jackd with :

jackd -R -d firewire -p 256 -n 3 -r 44100

and the same results with

jackd -R -d firewire -p 1024 -n 3 -r 44100

with -p 2048 or -n greater than 3 I get continuous XRUN's and jackd times out in a matter of seconds (weird).

Graphics card is Geforce FX5200 (128MB)

Window manager is fvwm, which has an annoying bug that sometimes dragging windows causes them to freeze while they are being dragged (FWIW). This doesn't seem to affect ardour.

Any help would be much appreciated.

Please let me know if I posted this in the wrong place and I will move it.

Such reports should go to the ffado-devel or ffado-users mailing list (see Contact).

At this time, FFADO is still experimental, so what you describe can happen. Use FreeBoB for the firepod.

ppalmers showed me which can do a bus-reset without the need to unplug/reboot the device. Very handy here where the device is inside a rack...

I've got two firepods daisy chained and they work very well each using its internal clock.
Typically I run jackd -R -d firewire -n 3 -p 32 -r 88200 and the configuration is stable - many hours and no problems.
I'd like to increase the number of inputs from 16 to 20 using two spdif inputs.
The extrnal devices are locked together with a wordclock so they should be presenting sunchronsed SPDIF to the firepods.
Increasing the latency 88200 does not seem to help within a minute I see an error

andrew@hector:~$ jackd -R -d firewire -n 3 -p 512 -r 88200
[..stuff deleted here..]
no message buffer overruns
JACK server starting in realtime mode with priority 10
1359197916608181: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.1.0- built Dec 27 2012 22:46:02
JackFFADODriver::ffado_driver_wait - unhandled xrun
firewire ERR: wait status < 0! (= -1)
JackAudioDriver::ProcessAsync: read error, stopping...

In another window, after the line starting 1359197916608181 was shown, I set the clock sources to spdif for both.
The unhandled xrun came within about a minute

Setting the clock rate to 48000 and repeating all is OK, even with period of 256. Stability for, well, at least as long as I've tried.

Any advice as to what I should do to get this level of stability at 88200 ?


It's hard to know based on the information at hand. Debugging this of course requires two of these interfaces and working through the issue.

One easy thing to check is to confirm that you're using a kernel configured as a "low latency desktop" kernel. In a terminal, type "uname -r" and post the result. If PREEMPT appears somewhere in the string then you are. If it doesn't then this may be pointing to the problem. In our experience, reliable operation of FFADO does require a PREEMPT kernel; a generic desktop kernel can be vulnerable to xruns.

Having said that, the problem may also come down to some other external (to FFADO/jackd) issue. Perhaps there's a daemon running on your system which somehow interrupts FFADO sufficiently to cause the xrun. There may be a hardware event occurring. But let's clear the kernel first and move on from there.

uname -a
Linux hector 3.2.0-37-lowlatency #37-Ubuntu SMP PREEMPT Mon Jan 28 13:38:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

The problem is specific to this dual spdif configuration. With no spdif and each firepod set to internal clock, the same equipment runs happily at jackd -R -d firewire -n 3 -p 64 -r 88200
jack_lsp shows 16 ins and 16 outs and my tests show I can connect anything and it works fine. Same computer, same kernel, etc.

As soon as I go run ffado-test -v 3 -n $FP SetClockSource 37
where $FP is 0 1 then the whole thing gets much less stable.
As i said I could run with spdif as clock source at 48000 for several hours with period 256, but not more than a minute or two at 88200.

I much prefer 88200, either its my imagination or its less audible aliasing, but 88200 seems to sound better.

Any reasoable advice welcome.

Thanks for confirming the kernel. I think it's safe to discount that as an issue. Furthermore, since things work with the internal clocks it does seem that the problem is caused by the specific clock arrangement you're trying to use. That arrangement should be fine, so we've got to try to work out why it doesn't.

Having re-read your original post in conjunction with your latest, it seems to me that you're starting jackd and then changing the clock source. Is there any particular reason for doing this? There are some good reasons why switching clocks while jackd is running could cause timing related issues. For this reason, many other devices actively prevent the setting of the clock source while streaming audio data. Have you tried switching clocks before starting jackd?

I don't have any personal experience with the firepod, but it should be possible to set the clock source before starting jackd and have that setting preserved by jackd. If that doesn't seem to work we should probably look into fixing that.

As a footnote to the previous posting, either firepod works OK alone at 88200 with either external A2D connected to its spdif input.
Completely stable at settings like jackd -R -d firewire -n 3 -p 128 -r 88200, working mostly OK at period 64
Interestingly, at 96000 not so, even at period 1024.

With two firepods daisy-chained, at 88200, ffado works great for jackd -R -d firewire -n 3 -p 32 -r 88200.
16 analogue ins and outs are stable all day.
Adding two external A2D, locked together with word-clock, each feeding the spdif in on one firepod,
everything is OK at 48000 (period 256) but 88200 seems completely unstable at any period on my config.
Any suggestions for a way to get 20 inputs at 88200?
jackdmp and ffado 2.1.0.

Sorry about the previous postings.

With better quality spdif cables - i.e. 75 Ohm - and a faster computer,
2 x firepod + 2 spdif ADC word-clocked together work faultlessly as 20 channels of input.
As I write I it is running at 88200, 32 frames/period and 3 period/buffer (i.e. 1.09 mSec latency)
using libffado 2.999.0 on a stock ubuntu "precise" installation with a lowlatency kernel - 3.2.0-55-lowlatency as they call it.