RME driver progress

After far too many delays (both technical and logistical,for which I apologise), practical progress has finally been made on the FFADO RME driver.

In short, the driver is now ready for wider testing, although there are some important limitations and cautions to keep in mind before proceeding. Read more for the details.

  • If a non-zero verbose level is selected using the "-v" option, a 0 dBFS 1 kHz sine wave will be output on the left phones channel. This is to facilitate debugging of audio timing. If you have headphones or monitors connected to the phones output, please do not activate verbose debug mode without taking appropriate precautions.
  • The level produced from the phones (aka monitor) output is very high from this device and the front panel "ph" level control does not affect the level being sent by the computer. Use headphones with extreme caution to prevent inadvertent hearing damage, especially during initial testing and/or if no software volume control is in operation.
  • You will need the latest subversion snapshot of FFADO.
  • Ffado-mixer support is still rather limited and contains only a small number of controls (now the streaming system seems to be working I expect to expand this soon). In particular there is no user access to the onboard mixer controls: however, ffado sets these to a 1-1 mapping which should do for testing.
  • Meaningful testing is probably limited to the Fireface400 for the moment since that is the interface I have been testing with. I will test with with a FF800 in due course - most likely after I've got a more complete ffado-mixer working for the ff400. In the meantime, it is almost certain that the driver will not run with a FF800 yet.
  • I've been testing exclusively with jack1 and the old kernel firewire stack. In theory jack2 should work just as well, but I have seen reports over the last couple of weeks which suggests that there may be a problem with ffado in the latest jack2. YMMV. Similarly the new kernel stack should work but I have not personally tried this yet.

To provide feedback on your experiences please subscribe to ffado-devel and post your findings there initially. If extended discussion is required we can take things off-list if appropriate.

My testing to date has been mostly with 48k and 44.1k rates. I have fired 96k and 192k up and had them work for short periods of time so hopefully that's a good sign. Finally, for initial tests it is probably wise to stick with fairly large latencies: I've been using "-p 1024" and "-n 4" options when starting ffado via jackd.


Unfortunately, due to a number of real-life issues unrelated to ffado I have not had the time I expected to have for ffado over the past 6 months. I've been able to assist in the debugging of a few important higher-level ffado issues, but larger-scale things have not been possible.

The status of the code with the ff800 is that it is yet to be tested with that device. The driver as written should be capable of driving the ff800, but as with anything like this there are always a few issues to sort out during debugging. People are certainly free to try their ff800 with the existing driver to see what happens. While the same driver is starting to work acceptably with the ff400, the ff800 does differ from the fff400 in several important ways at the hardware level (which you can notice due to the presence of various ff800 optional branches in the code, for example). This is why it really has to be debugged. There should not be much in the way of code which needs to be written from scratch at present.

At the start of this year my initial plan (after getting audio streaming working with the ff400) was to get some sort of rudimentary support for the ff400 mixer happening. Again, there's little in the way of coding needed for this - it's more "handle cranking" sort of work. Then I was going to start on bringing the driver up for the ff800. Clearly that isn't how the year has turned out - and I'm as disappointed as anyone else with this.

Having said all that, I really do want to start making some more progress on this soon, and I'm hopeful that circumstances are going to let this happen over the next few months. My tentative plan is probably along the lines of what I outlined above, but I may at least do some initial debugging on the audio side of the ff800 sooner, if for no other reason than to prove that things are coming together.

As you may have read elsewhere on the ffado site, the ff400 entered the "basic testing" phase earlier this year.

So to directly answer your question, I can't give any ETAs on the "basic testing" of the ff800. Until I've brought the interface up there's probably not a lot of scope for external help since I can't pass the device documentation on (even then, most of the code is already in place, notwithstanding bugs which need to be discovered and fixed). This bottleneck is one of the reasons I may bring the "basic testing" of the ff800 forward, so others at least can start doing something with the interface and provide feedback, suggestions and so on.

Thanks for checking back regarding the status of the ff800, and I an very sorry that I haven't been able to provide anything in the way of positive news. I am however very much aware that many are waiting for the ff800 to come up under ffado, and I want to reward your patience as soon as I possibly can.

Where can I find the driver for RME Fireface 400?

I am also wondering about this, pardon for this is not my forte. But any help would be appreciated. Thanks

The driver for the Fireface 400 (and Fireface 800) is included in FFADO version 2.1.0. Things required by a majority of users are supported: all device controls should be usable via ffado-mixer and audio streaming works. Things still to be done which are relevant to the FF400 and FF800 are MIDI I/O and the storage of device configuration to NV RAM (the latter is being worked on now). In addition, the TCO option for the FF800 is still to be done.

Got Presonus StudioLive 1642 working!

Thank you, for your excellent work!

- Koivukoski1

Thanks for the report.

Fairly obviously this isn't related to RME progress. However, until now we haven't had a device entry for the Presonus Studiolive 1642. I've now created one at http://www.ffado.org/?q=node/2488. If you have the time, it would help other users in future if you could post details of what you had to do onto this new device page. Even if everything worked "out the box" (so to speak), saying this will help other users to know that things can be made to work. Noting the FFADO version would also be worthwhile.

Hi JW,
whena I launch "play" with an exampole file of qutecsound nothimg happens.
In the message window of qtljack appears:
"Tue Jul 31 01:23:19 2012: New client 'csound-tmpTTwZ58' with PID 5893
Tue Jul 31 01:23:19 2012: Client 'csound-tmpTTwZ58' with PID 5893 is out"
And nothing more happens


I must admit that I'm completely unfamiliar with qutecsound or csound itself. Since other jack-enabled applications are able to playback my guess is that there's something that qutecsound or csound is not doing. For example, there may be a need to manually connect csound jack ports to the playback ports of the RME provided by jack/ffado. If this hasn't been done the csound output isn't being sent to the RME and therefore no output will be heard. Another option is that csound is not using jack by default and needs to be told to do so.

Having a look at http://www.csounds.com/manual/html/UsingRealTime.html, it seems that something like this might be going on. Scroll down to the section "Using jack" (near the bottom of the page, about five sixths the way down). Here it says that the default action is not to connect csound output ports to anything so this will need to be done manually or via something which automatically handles such things (a jack session manager, or perhaps qjackctl if configured to do so). It also shows that there's a need to explicitly request that csound use jack (the default is to use something else - portaudio I think, but I haven't read the document closely so I might have mis-interpreted it).