Recently I've been trying to get a Focusrite Saffire Pro40 working on my HP EliteBook 8540w, currently running Fedora 20 with CCRMA RT kernel.
I eventually pieced together enough information from various web sources to get it working, but the issue I have now is that qjackctl reports xruns - sometimes one every couple seconds, sometimes several minutes apart - even with nothing connected through jack. If I play something using sndfile-jackplay[*], I notice that, around the time of each xrun, there's a 1- to 2-second gap in sound output (on headphone out 1), during which time the player app also freezes. I've tried setting large values for frames/period and periods/buffer -- up to 1024 and 64, giving a whopping 1.49 seconds of latency at 44.1 kHz. While the xrun frequency tends to be higher with smaller latencies (< 10 ms say), the variation is pretty small compared to trial-to-trial variation, so I can't say for sure. Also I've noticed that after the sound returns after a gap, there's some distortion. including something that sounds vaguely like a high-hat cymbal closing softly, about once a second or so. It gradually fades away after a few seconds. (Weird, eh?)
The Pro40 was purchased new from a large on-line retailer at the end of 2013. It's still running the original firmware (nothing I've read so far said conclusively there was any benefit to upgrading), and it's been connected to Focusrite's MixControl (on a Mac) only once, and that was brief - just to see if MixControl recognized it.
Although it may not be a very useful comparison, I've also used an M-Audio Fasttrack Pro (USB) interface with this same lap-top on and off for months with only an occasional xrun - but that's been mostly on the stock kernel. With the RT kernel I've yet to see an xrun, although the machine locked up once when I was playing from Ardour3 -- the sound kept playing, but since the UI was unresponsive and I couldn't log in over the network, I resorted to holding the power button down.
ffado-dbus-server throws quite a number of ominous-looking errors at various times, although they don't seem to correlate to the xruns in time. I can provide output if it would be useful.
ffado-diag output starts with the following:
> kernel version............ 3.12.12-300.rt19.1.fc20.ccrma.x86_64+rt
> Preempt (low latency)... False
> RT patched.............. True
> old 1394 stack present.... False
> old 1394 stack loaded..... False
> old 1394 stack active..... False
> new 1394 stack present.... True
> new 1394 stack loaded..... True
> new 1394 stack active..... True
> . . .
> Host controllers:
>46:06.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 06) (prog-if 10 [OHCI])
> Subsystem: Hewlett-Packard Company Device [103c:1521]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 64 (500ns min, 1000ns max), Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 20
> Region 0: Memory at d3101000 (32-bit, non-prefetchable) [size=2K]
> Capabilities: <access denied>
> Kernel driver in use: firewire_ohci
> Kernel modules: firewire_ohci
I can provide the rest of that output if it's useful too.
I'm curious as to why it reports "False" for preempt (low latency) on the CCRMA kernel -- I guess I was thinking that was part of the RT patches, but apparently that isn't the case...
I see FFADO has a new version (2.2.1) out a couple months ago. I've been thinking about trying that, but what I've read has led me to expect that this interface should work with 2.1.
I'd love to hear what others have experienced.
[*] - I'm pretty sure I built this from source, as I couldn't find it in Fedora or CCRMA repositories. (I was kind of surprised about that, since these sndfile utilities seem quite useful.) Anyway the rest of the system is pretty much stock, and up to date a of a couple days ago.