Saffire

Note that the onboard DSP effects are currently not supported. The mixer is supported.

Support Status: 
Full Support
Manufacturer: 
Focusrite

Comments

With a new arch linux install, the "stock" ffado (v2.0.1-5) and jack2 (v1.9.8-1) packages do not recognize the device. This is independent of jack2 vs jack2dbus etc.

However AUR "libffado-svn2011-1" (HEAD of trunk in SVN) as of 23Mar2012 resolves all that, so that ffado-test and ffado-diag all give correct results and ffado-mixer comes up with healthy appearance and function etc. So the dbus event side is all good, driver load is all good, and basics on ffado side are all good.

Unfortunately at the moment there is no way to obtain a corresponding and functional jack daemon.

Last built-out "release" version of jack2 (git tag "release-1.9.8") rejects the above build of ffado due to version difference and check (9 vs 8).

Building the latest dev version of jack2 (from git) fails to build due to link error (plus numerous compile warnings).

Dropping back to jack1 for hope of relief; no joy there. The last "release version" of jack package (v0.121.3-5) rejects ffado similarly, as one might expect. The latest development version builds just fine, but then goes on to crash during invocation. (details available but not here for brevity)

I doubt very much that these latter problems have anything specific to do with this device; however, there remains no way to get a working set of juju/jack/ffado together, with this device.

I would be extremely helpful for a coherent set of tags to be made at the last functional revisions that build, work together, and recognize supported devices; this probably was just before the recent driver API extension occurred.

Lacking this, once the current issues on the development trunk/head are overcome and demonstrably working (at all), it would be extremely helpful to tag revisions that work together as "recommended-vX.Y.Z" (say).

> Unfortunately at the moment there is no way to obtain a corresponding and functional jack daemon.
>
> Last built-out "release" version of jack2 (git tag "release-1.9.8") rejects the above build of ffado due to version difference and check (9 vs 8).

This, this is unfortunate and comes about because old jack versions (both jack1 and jack2) were fairly intolerant of FFADO versions different from the precise FFADO version they were compiled against. As of FFADO r2106, FFADO has the ability to detect whether the system's jack is "old" at compile time and activates a workaround so it will at least work without necessitating an upgrade of jack.

> ... however, there remains no way to get a working set of juju/jack/ffado together, with this device.

Yes there is: use the latest git versions of either jack1 or jack2. Both should work (I have personally tested jack1). It is not unreasonable that development versions of FFADO (which is after all what trunk is) will break things from time to time and possibly require updated versions of other tools such as jackd.

> I would be extremely helpful for a coherent set of tags to be made at the last functional revisions that build, work together, and recognize supported devices; this probably was just before the recent driver API extension occurred.

Indeed it was. So you can go with:
* jack1 0.121.3 (or jack2 1.9.8) with any FFADO version <= r2077 or >= r2106
* jack1 0.122.0 (or jack2 1.9.9) (in git at present) with any FFADO version >= r2078 (and possibly < r2078 as well)

The short answer: if you don't want to upgrade your version of jack, just grab FFADO r2106 or later and be happy. You won't get jack's setbufsize support until you do upgrade jackd, but that's unavoidable because the firewire front-end in
the older jacks - as well as being intolerant of FFADO API version increments - also lacked the required code to support dynamic buffer resizing with FFADO.

> it would be extremely helpful to tag revisions that work together as "recommended-vX.Y.Z" (say).

I doubt this will happen: as is the nature of development trunks it's very hard to nail an arbitrary development revision is "good" in all cases. As soon as you think you have something nailed something else inevitably crops up. This means that you end up chasing your tail and have different recommendations for different devices. The resulting support burden is not sustainable given the current resources of the FFADO project.

What I can say is that we are in the process of attempting to stabilise things for a possible release of the long-overdue version 2.1.0 later this year. There are a lot of tickets we need to catch up on first, but the work has started and we continue to make progress. This will then effectively become the recommended version for users, with the intention that future versions will be released far more often than we've managed over the past 18 months. I should note that while this is my intention it does depend on the core developers having the time to make this happen - something which wasn't the case over most of 2011 and was the single biggest cause of the lack of timely releases over that time frame.

Hi there. I need a little bit of help. I have a focusrite saffire (white model) firewire connection, and I cannot start the ffado mixer. I followed the instructions from this website, and they helped me a lot. There is also a discussion about my problem there, with screenshots and everything.

http://www.audiorecording.me/focusrite-saffire-pro-40-in-ubuntu-11-10-in...

http://www.audiorecording.me/music-production-help/67/can-set-firewire-s...

Please help me...!

Thanking you in advance!

George Georgiadis

Hi George

In order to provide assistance we need to know a little more about your system, what you've tried and what happened when you did. Of the URLs you provided, the first seems to just be a fairly comprehensive outline of how to get FFADO working in Ubuntu. The second mentions some issues in a generic sense, but unfortunately I can't quite understand what the problem actually is from the ensuing discussion.

To make progress in all this we need to determine what works for you and what doesn't. From the second URL it seems that you have two problems. The first is that jackd (via qjackctl) stops for no apparent reason. Is this correct and reproducible? The second is an indirect reference to ffado-mixer not working, which ties back in with the subject of your initial comment on the ffado website. So is it fair to say that the primary problem is ffado-mixer's failure to function?

Assuming ffado-mixer has issues, we will need you to provide further information. First up, please run ffado-mixer and post here the output that it produces. This may give a clue as to what's going wrong. We can then determine the most appropriate course of action (which may be the opening of a ticket to coordinate further debugging).

I should note that I myself do not own any Saffire interfaces; while I can help with some of the basic ffado functionality, if things require a more indepth knowledge of the interface I will have to defer to others who have had success with them.

Finally, in the second URL you wrote:
I send twice a mail to www.ffado.org and they didn't answer me!
Where did you send your emails to? Are you referring to this post on the website instead? Or did you send it via the web inquiry form? If the latter I can only apologise for the delay in a response; emails sent via that form are triaged by someone who is very busy with other real-life things at present so it can take some time for the rest of us to be made aware of them. Somewhat related to this, it should be mentioned that none of the FFADO developers are paid to work on FFADO: we all do this in our spare time. As a result, there can be delays responding to posts on the website (and so on) just because other things (paid work, family, etc) mean no FFADO time for a while. This is precisely why I am only seeing your initial post some 2 days after you wrote it.

Greetings, I too need a little bit of help. I have a Focusrite Saffire pro 40, and regardless of everything I've tried in reference to various instructions (on this site as well as others), I cannot estblish a connection with the ffado mixer. I am currently utilizing Ubuntu 12.04 (Xfce desktop environment). Upon attempting to initiate ffado mixer from the terminal this is what I get:

First entry:

ken@ken-desktop:~$ sudo apt-get install ffado-dbus-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
ffado-dbus-server is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.

Second entry:

ken@ken-desktop:~$ ffado-mixer
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/ffado/ffadowindow.py", line 124, in tryStartDBUSServer
subprocess.Popen(['ffado-dbus-server', '-v3']).pid
File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

Any assistance to get me up and running would be greatly appreciated.

t_1

This is an interesting one - I haven't seen this error before. I'm also not a python expert, so what follows may be a little general. However, let's see how we go.

The python error messages appear to be saying that it can't start the ffado-dbus-server process, and yet your package manager seems to be convinced that it's installed. Probably the best thing to do is to attempt to run ffado-dbus-server manually on the command line and see what happens. If it runs then we have to look into why python can't start it. However, if it errors out the resulting error messages may give some clue as to why it's not starting.

Hello,

I'm trying to get my Focusrite Saffire to output audio under Ubuntu 12.10. I've gotten to the point where FFADO-mixer is running and I can get jackd to run but it aborts after some time, by itself. My interface powers on, lights up like it does under Windows, but no audio comes out. Also, my media players don't really 'play' i.e. the tracks either aren't able to be found (even after importing) or do not progress in time.

Also another discrepancy is when I run 'ffado-test Discover,' it asks for libffado 2.1.9999.2276, whereas when I am activating the ffado server, it asks for libffado 2.999.0. I had to delete the libffado 2.1.9999.2276 library and re-linked the libffado.so to lib.ffado.so.2.999.0 under /usr/local/lib

There is another instance of libffado under /usr/lib, version 2.999.0 as well.

Also, when I run ffado-dbus-server, there are two ieee1394service.cpp errors (initialize: could not set SPLIT_TIMEOUT to min requested, did not succeed).

Any way you can help get my Saffire working under Ubuntu 12.10?

Thank you!

Eric

Hi Eric

You raise a number of issues in your post. I'll try to deal with each in turn as best I can. Please keep in mind that I don't own any Saffire devices and therefore I have no direct experience with them myself.

First up, in order to make specific recommendations we'll need to know which Saffire interface you have. It would also be useful to know which firmware version has been loaded.

Before dealing with the start-up abort we need to resolve the library issue. It would seem that you might have compiled ffado 2.1 yourself. This is fine but there are a few things you need to take care of. First up, when running scons to compile ffado, you should include "PREFIX=/usr" in your scons command. This will result in the new FFADO overwriting the old, thereby avoiding a number of potential issues you can have when the location of some shared libraries change.

In your case, the PREFIX setting was not given so ffado was installed in the default location: under /usr/local/. As you have noticed, you're left with two different instances of ffado on your system. This will need to be resolved before we can proceed with other fault finding tests because it's unclear which libffado version was being used by the different components. To uninstall the new version, "scons -c install" should do the trick when run from inside the libffado source tree. This will also completely clean the source tree of compiled objects, but that's fine. After running this, check /usr/local/lib to ensure that libffado* is indeed gone.

Next up, recompile ffado but include the PREFIX setting: "scons PREFIX=/usr". When complete, "scons install" should install the new ffado over the old but with one important caveat: since the version of the shared library was changed with the release of version 2.1, the installation of the new ffado will not overwrite the old shared library. /usr/lib/ will therefore contain two libffado.so* shared libraries: libffado.so.2.999.0 and libffado.so.2.1.9999*. Due to an inadvertent error some years ago which was only noticed during preparation for the release of version 2.1, it turns out that the former (2.999.0) is the old one and is the one which needs to be removed. You should also be able to confirm the older one using the timestamps on the files. Once done, running "ldconfig -n ." in /usr/lib/ should fix up the symlinks for you.

Once this is done, the complaints about the libffado version by ffado-test and ffado-dbus-server should be resolved. Jackd should also use the new version. Assuming all is as described, please re-test so we can determine what is going on when the new ffado is being used by every component.

Finally (for now at least), the errors relating to SPLIT_TIMEOUT can be ignored. In fact, when ffado 2.1 is in use I don't think those messages are displayed as errors any more.

I hope this helps. Let us know if you need any of the above clarified.

Thank you much for your reply! The Saffire interface I have is the white and silver one (not LE). It has the latest firmware (not sure what ver#) installed.

Unfortunately I chose to reinstall the OS and re-build and compile the FFADO drivers and JACK since I was afraid I had an installation issue with the ffado libraries, and this was before I saw your reply. During the second installation I realized I had not installed all the proper dependencies last time, and made sure of this before I compiled FFADO.

Now, I was able to get audio from youtube in Firefox, GNOME Mplayer, and Banshee (which I read shouldn't work?). That part is good.

The bad part is that the interface appears to be rather unstable. Here is the most common QJACKCTL error message I'm receiving when I run an mp3 player like GNOME or Banshee, after I run QJACKCTL:

Wed Mar 20 22:25:57 2013: [1m[31mERROR: JackFFADODriver::ffado_driver_wait - unhandled xrun[0m
Wed Mar 20 22:25:57 2013: [1m[31mERROR: firewire ERR: wait status < 0! (= -1)[0m
Wed Mar 20 22:25:57 2013: [1m[31mERROR: JackAudioDriver:rocessAsync: read error, stopping...[0m
Wed Mar 20 22:25:57 2013: Jack: JackPosixThread::ThreadHandler : exit

I have tried many things, from irq tweaking to disabling my wireless card, to running jackd before qjackctl, to running qjackctl as root, to setting my cpu to performance mode. Nothing gives me a permanent fix. It works sometimes, but most times does not.

Any further help would be greatly appreciated. I just want the system to reliably play music...

No problem about the reinstall. It appears to have improved things somewhat.

The most common cause of regular xruns is a system which is not scheduling jackd/ffado frequently enough to keep up with the demands of the hardware. You have already tested a number of the usual suspects (wireless card, CPU frequency mode not fixed at the highest speed, and so on).

At this stage, we really need to see the output of the "ffado-diag" command on your computer. This will tell us a number of things about your hardware and the system you have running, and will allow us to identify any deficiencies in that area.

At this stage I am wondering whether your system is running a PREEMPT kernel. With most hardware this is a requirement to get reliable audio operation, especially with FFADO. Such a kernel is available from many distribution repositories, and sometimes goes by the name of "low latency desktop". Having said that, this is really just a guess and will remain so until we see the "ffado-diag" output.

Hello. Thank you for your reply. As you requested here is the output of ffado-diag. I will look into the PREEMPT kernel.

FFADO diagnostic utility 2.1.9999-2276
============================
(C) 2008 Pieter Palmers
2009-2010 Arnold Krille

=== CHECK ===
Base system...
kernel version............ 3.5.0-26-generic
Preempt (low latency)... False
RT patched.............. False
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
/dev/raw1394 node present. False
/dev/fw* permissions:
crw------- 1 root root 250, 0 Mar 30 12:37 /dev/fw0
crw-rw----+ 1 root audio 250, 1 Mar 30 12:37 /dev/fw1
User IDs:
uid=1000(ericzhang) gid=1000(ericzhang) groups=1000(ericzhang),4(adm),24(cdrom),27(sudo),29(audio),30(dip),46(plugdev),107(lpadmin),124(sambashare)
Prerequisites (dynamic at run-time)...
gcc ............... gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
g++ ............... g++ (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
PyQt4 (by pyuic4) . Python User Interface Compiler 4.9.3 for Qt version 4.8.2
jackd ............. jackd version 0.121.4 tmpdir /dev/shm protocol 24
path ............ /usr/bin/jackd
flags ........... -ljack
libraw1394 ........ 2.0.9
flags ........... -lraw1394
libavc1394 ........ 0.5.4
flags ........... -lavc1394 -lrom1394 -lraw1394
libiec61883 ....... 1.2.0
flags ........... -liec61883 -lraw1394
libxml++-2.6 ...... 2.34.2
flags ........... -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0
dbus-1 ............ 1.6.4
flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -ldbus-1
Prerequisites (static at compile-time)...
gcc ............... gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
g++ ............... g++ (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
PyQt4 (by pyuic4) . Python User Interface Compiler 4.9.3 for Qt version 4.8.2
jackd ............. jackdmp 1.9.9
path ............ /usr/bin/jackd
flags ........... -ljack
libraw1394 ........ 2.0.9
flags ........... -lraw1394
libavc1394 ........ 0.5.4
flags ........... -lavc1394 -lrom1394 -lraw1394
libiec61883 ....... 1.2.0
flags ........... -liec61883 -lraw1394
libxml++-2.6 ...... 2.34.2
flags ........... -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0
dbus-1 ............ 1.6.4
flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -ldbus-1
uname -a...
Linux ericzhang-MS-7350 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:18:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Hardware...
Host controllers:
05:09.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev c0) (prog-if 10 [OHCI])
Subsystem: Micro-Star International Co., Ltd. Device [1462:350d]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci

CPU info:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 15
Stepping: 11
CPU MHz: 3003.000
BogoMIPS: 5999.99
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
NUMA node0 CPU(s): 0,1
Configuration...
IRQ information
Hardware Interrupts:
--------------------
IRQ 0: PID: None, count: [44, 0], Sched None (priority None), drivers: ['timer']
IRQ 1: PID: None, count: [11, 0], Sched None (priority None), drivers: ['i8042']
IRQ 4: PID: None, count: [2, 0], Sched None (priority None), drivers: ['']
IRQ 6: PID: None, count: [5, 0], Sched None (priority None), drivers: ['floppy']
IRQ 7: PID: None, count: [1, 0], Sched None (priority None), drivers: ['']
IRQ 8: PID: None, count: [1, 0], Sched None (priority None), drivers: ['rtc0']
IRQ 9: PID: None, count: [0, 0], Sched None (priority None), drivers: ['acpi']
IRQ 12: PID: None, count: [4847, 0], Sched None (priority None), drivers: ['i8042']
IRQ 14: PID: None, count: [0, 0], Sched None (priority None), drivers: ['pata_amd']
IRQ 15: PID: None, count: [297, 0], Sched None (priority None), drivers: ['pata_amd']
IRQ 16: PID: None, count: [6182, 0], Sched None (priority None), drivers: ['nvidia', 'nvidia']
IRQ 17: PID: None, count: [94, 0], Sched None (priority None), drivers: ['firewire_ohci']
IRQ 19: PID: None, count: [351, 0], Sched None (priority None), drivers: ['sata_sil24']
IRQ 20: PID: None, count: [19131, 0], Sched None (priority None), drivers: ['sata_nv']
IRQ 21: PID: None, count: [0, 0], Sched None (priority None), drivers: ['sata_nv']
IRQ 22: PID: None, count: [81, 0], Sched None (priority None), drivers: ['ehci_hcd:usb1']
IRQ 23: PID: None, count: [132957, 0], Sched None (priority None), drivers: ['ohci_hcd:usb2', 'eth0']

Software Interrupts:
--------------------

=== REPORT ===
FireWire kernel drivers:

The new FireWire kernel stack is loaded.
If running a kernel earlier than 2.6.37 and problems are experienced, either
try with the old Firewire kernel stack or upgrade to a newer kernel
(preferrably 2.6.37 or later).

Thanks for the info. As is evident from the ffado-diag output, your kernel is neither a PREEMPT or RT kernel. In many cases this is sufficient to cause xruns. Please do look into getting a PREEMPT kernel installed on your system as you suggested, and then re-test. If the xruns continue to occur then we can look for other potential causes. While a non-PREEMPT kernel is in use there is a strong possibility that it is the cause of most (if not all) of the problems.

Hi - thanks for writing.

I have since installed a low-latency kernel on Ubuntu 12.10, but it causes massive lag/slowdown/crashing on my system, rendering it unusable. I wasn't able to test whether the audio was working, since it freezes shortly after starting qjackctl.

I have tried installing Ubuntu Studio, which by default contains the low-latency kernel. This didn't work either. Then I by mistake updated to nvidia drivers, causing it to be stuck at 640x800 resolution. Subsequent installs of Ubuntu Studio did not work - the installation is extremely buggy. I may go back to trying to get my other (USB) interface working with Linux, since I'm running out of options with my Saffire...

The behaviour of your system with the low latency kernel is very interesting - I don't recall hearing anything like that before. The low latency kernel really shouldn't behave significantly different to any other kernel. Obviously it's not possible to debug something like that here but it does sound rather irregular, especially since a "normal" kernel apparently works fine on the same hardware. Although it makes little sense, it may be worth getting hold of memtest86 and letting it run through a few times: perhaps there's a hardware issue in the computer, and memory tends to be the one of the first things to check because running memtest86 is so easy. The other option of course is that there's something about your hardware which the low latency kernel doesn't like for some reason, but this sort of thing tends to be extremely rare in this day and age.

Do let us know how you get on. I know others are using the Saffire successfully, but your hardware is almost certainly different. I would love to get to the bottom of the strange behaviour you're seeing, but I fully understand if you choose to move on to something which happens to work on your hardware.