AudioFire 12

As of August 2012, the Audiofire 12 will only work with FFADO if firmware 4.8 or earlier is installed in the device. Please refer to ticket #360 for more details and for news about progress in fixing this.

28 Oct 2013: Takashi Sakamoto has pointed out that firmware versions 5.5 and later no longer support 192 kHz sample rate. This is a hardware limitation and is not related to FFADO. It is not currently known why this rate is no longer supported. To continue to use 192 kHz sample rate, stick with firmware version 4.8.

29 Oct 2013: As of r2451/r2452, audio streaming with FFADO may now be functional with AudioFire-12 firmware versions 5.5 and later. Reports of tests are welcomed. This is thanks to Takashi Sakamoto.

Support Status: 
Full Support


So on 10.04 (before I think the introduction of the new FW stack juju) I had a perfectly stable jack system. Since upgrading, no matter what jack period settings, xruns are appearing about once a minute (when idle!). Since the only thing that really changed was the new FW stack, I'm assuming that is the cause...)

My system:
* A custom kernel (only bumped the clock Hz to 1000)
* libraw1394-11 2.0.5-2ubuntu1
* jack2 1.9.5
* libffado2 2.0.1

I've set my /etc/security/limits.conf appropriately. My udev settings are masking /dev/raw* and /dev/fw* (though I think the latter is what is used by the new stack, since I had to add that after upgrading).

I've tried using the svn trunk version of ffado as well with the same result. Additionally, with the svn trunk, my Audiofire 12 has 13 audio connections and no midi connections, so I think there is some incorrect classifications going on (but I'm not sure if that's ffado or jack).

Any help would be greatly appreciated, because one xrun a minute (when idle) isn't really usable. Let me know if there is any more information that would be helpful to be included.

I have a similar problem: everything was working well until the upgrading to maverick. But now I can't even start my audio engine.

Do you have any success? I was trying to install last real-time kernel I've found (2.6.33 on ) because I realised that Maverick lacks on RT-Kernel. But I have no idea how to solve this.

I don't have an AF12 or any experience running ffado under ubuntu so my ability to assist here is somewhat limited. I have a few general pieces of feedback for you though.

Firstly, since you report that everything was good under a previous version of Ubuntu then it's safe to assume that the hardware is good. That eliminates a whole host of potential issues.

The new FW stack is certainly something to consider here since it is clearly the most obvious thing that's changed. However, with every new kernel comes new drivers and improvements to others. As a result, the xruns you're seeing now *may* be the result of some new feature in one of the other kernel drivers your system uses. Perhaps it has adversely affected the scheduling on your system, with xruns under ffado the observed result.

Having said that I must admit that I suspect the new stack is at least part of your problem here. To test this the first thing I would do is obtain the latest stable kernel (which is 2.6.37) and give that a go. There have been a number of important fixes to the new firewire stack since 2.6.35. On a related subject, also check the version of libraw1394 on your updated system. If it's not 2.0.6 then try to upgrade - I think one needs 2.0.6 in order to get reliable ffado operation under the new stack.

Another thing which may be different is your video driver. I don't know what drives Ubuntu ships, but it's not unheard of for video drivers to adversely affect ffado. In particular, we know that the proprietary binary drivers from Nvidia can cause very strange effects not unlike what you're seeing. If your system is running such a driver and it's feasible to temporarily switch to another this might be a good thing to test. Perhaps the older Ubuntu didn't install the proprietary driver on your hardware, or maybe it shipped a different driver altogether.

Finally, with recent kernels (and anything from 2.6.30 is "recent" in this context) ffado should not require a realtime patched kernel in order to function acceptably. This is because various things from the RT patch have been trickling into mainline over recent times, and we've finally got enough of them across that mainline works fairly well for ffado now. The only caveat is that the "low latency desktop" preemption setting should be enabled.

To avoid confusion it should be explicitly pointed out that in order to use the realtime scheduling class (enabled in limits.conf) one does not require an RT kernel. Although both refer to the words "real time" they are in fact separate things.

Sorry I can't provide any more specific help. Hopefully the above is useful. In the meantime perhaps someone else who actually has an AF may respond.

MOTU 828MKII will not work out of initial install on Ubuntu 10.10. ffado giving me Could not communicate with DBUS service.

Yes, another fine time waster in the life of humans trying to master their machines. This worked in an older release of Ubuntu ... maybe two releases back for me.

All I wanted to do was install, plug my bass and keyboards in and do something more MUSICAL with my time. But, No..... not today... buddy boy...

On Ubuntustudio 14.04, the stock libffado suffers from the previsouly described problem (ticket 360) with Echofire firmware 5.8.1, the latest at the time this is written.
However building libffado from source using the latest svn is easy and compatible with the stock version of Jack (at May 2014)
I can report two Echofire 12 working together successfully to give 24in/24out, even with a low power laptop ( Dell Latitude E4300 )

build process:
1) install the necessary to compile libffado:
# apt-get build-dep libffado
2) Get ffado from svn.
# svn checkout ffado-svn
(I put it under /usr/local/src)
3) compile. You want /usr as the target to be sure the stock version is overwritten. Helpfully this is the default
# scons install

That's all - it works.

For more info see

Thanks to all who made this possible. PPalmers et al, Takashi, the people at Echo Audio

Andrew, thanks for taking the time to post your experiences with the new code. On the basis of this information I have closed ticket 360 as "fixed".

libffado 2.2.1-1
jack2 1.9.10-1

Does anyone elses card enumerate ports like this:
001486a296a59815_Unknown2_out... etc?
With an unusable non existing port at the end?

I wrote Echo about it, but they referred me to whomever wrote the driver.

Their response was:

"I don't have much experience with the ffado driver, it not being developed by us. It looks like it is enumerating the ports based on the serial number of the AudioFire 12; I'd try contacting whoever wrote that driver and see if it's something that could be adjusted on their end."

Is anyone else interested in trying to fix this or helping me patch it?


First up, I don't own and AudioFire devices so I can only speak generically based on the devices I do develop for.

There are two issues at play with the names: the first being the number at the start, and the second being the "unknown" tags used at the end. The first issue - that of the number at the start of the name - is indeed related to the serial number of the interface. This is used to ensure the generated port names are unique in the event that two or more identical interfaces are connected to the same computer. This approach was debated at length several years ago and it was decided that the above was the best way to go. I can't recall the specific reasons off-hand though.

It's not just the audiofire device which includes serial numbers in port names: it's done for every FFADO device as far as I know.

The second issue is that of the "unknown" tags. I believe that the audiofire driver queries the interface for the names of its ports. If this query fails then "unknown" is substituted. I cannot guess why the query might be failing in your case. Perhaps it's a firmware issue, or maybe FFADO has a but which prevents the names being processed correctly. Other AF12 users may be able to comment on this further.

If you don't like the port names (and I'll admit that they are less than descriptive in your case) it is possible to use jack port aliasing to assign more convenient names. My understanding is that the use of port aliases varies between different jack applications though - some use them while others ignore them. You'd have to experiment to see if the aliases work for you in a sensible way.

Thanks for the reply. If I get brave I'll try some different firmwares to determine if I can solve the real problem of the driver querying the ports.

Is there any chance you might know something about one more question.

My soundcard, by default - will send each input port to it's corresponding output port.
In1 -> Out1
In2 -> Out2 etc.

This is completely outside of the scope of JACK, as when no port connections are made with JACK, a microphone connected to port 1 will always be routed to the output port 1. You can see it clearly on the front VU meter.

Anywho, this is can be remedied with and only with ffado-mixer afaik. I can see how the input ports are routed to each out and turn that off. However, this setting is not saved on boot, so I have to manually turn down every channel every time I turn on the machine. Do you have any idea if there is either a way to make it permanent, or at least a CLI method of accomplishing the same thing so I can script it.

Unfortunately I do not know the internals of the AudioFire interfaces well enough to know whether this configuration can be saved within the device for later recall, or must always be set from software.

There may be a way to script this. The ffado-mixer GUI is just a graphical front end to the ffado-dbus-server program which is responsible for sending mixer commands to the AudioFire. The two are connected via dbus. If you find a program which permits you to send dbus messages, it should be possible to script the required messages to set up the routing which you desire. I have not personally done this myself, nor do I know of a suitable messaging program. I'm guessing there must be something like this around though, and if so then this should be feasible.

Another approach would be to write a small program that generates the dbus messages - an automated ffado-mixer type thing for example.

I have just noticed that another user has written a script to do the kind of initialisation I was talking about. It's for a different device but I imagine it could be generalised. Refer to their initial comment for more details and a link to the script.