[PlanetCCRMA] Fedora 20 3.12.12-300.rt19.1 with Focusrite Saffire Pro40

[Don Estabrook]

Hello -

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
> . . .
> Hardware...
>   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.

Thanks,
Don

[*] - 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20140818/22eed547/attachment.html