RME Fireface news

  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.

Thanks to assistance from RME we now have Fireface devices and documentation to assist in the development of the FFADO RME driver. Some low-level changes have been flowing into the development trunk for a few weeks now and high-level functionality will follow once the necessary parts are in place. There is no ETA at this stage, but support for RME Fireface devices is on its way.

Update: 6 January 2011: progress has been slower than I wanted but steady, and I think the end is in sight. Check out the extended update posted on the FF400/FF800 device information pages. In short, it's hard to give specific ETAs because of "real life" commitments, but at this stage I'm hoping to get the FF400 driver into a state fit for wider testing around Feb/March, with similar FF800 support to follow around Q2 this year.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Go Jonathan

Please Jonathan you can do it! We believe in you! I'd love to do some pre-alpha testing when you have something available.

Thanks and good luck!

RME fireface news (update)

For those following along at home I thought I'd fill you in on the current status. As of svn rev 1883 it is possible to have two-way audio streaming with a Fireface-400 (or at the very least, it worked on my development box tonight). In reality it was working after the previous batch of RME changes, but the device's matrix mixer was being initialised with all sends muted - so audio sent by the PC was muted before being passed on to physical output channels and no output was heard from the device. Rev 1883 fixes this - there is now a 1:1 mapping from playback channels to physical outputs by default so audio sent to "phones" for example now appears on the "phones" output.

There are some caveats though - so all this is still really pre-alpha at this point. I've only tested it at 1x rates (both 44.1 kHz and 48 kHz). Startup is still a little dodgy: about 1 in every 4 attempts the device does not start streaming (I'm still looking into this and have a few theories). The driver only provides access to the analog 1-2 and phones playback channels (although I'll extend this soon). Finally, operation at 48 kHz doesn't appear to be quite as stable as at 44.1 kHz, although more testing is needed to quantify this. The issue was that during 48 kHz operation the audio was interrupted about once every 90 seconds for about 1/4 second, followed by a short burst of digital noise and a resumption of audio (no ffado xruns triggered). This may be related to the startup issues noted previously; we'll see.

While much of this work also applies to the Fireface-800 (and FF-800 specific code has been written where necessary) I have not yet tested it with a FF-800. My plan is to get the FF-400 working first and then to start on the FF-800 - at least then I'm starting with code which is known to be mostly functional.

The exercise with the matrix mixer at least proves that the low level code to control the matrix mixer works. That gives a solid foundation for ffado-mixer support once the issues with streaming have been ironed out.

Re: Go Jonathan

Thanks for the encouragement. Progress is being made. FYI I have managed to record audio from the RME via jackd/ffado so we're part of the way there. At this point I have been unable to output audio from the device and it is this that I'm working on now. Once that is done it will be ready for wider "pre-alpha" testing I suspect. Again, no ETA on this though - at this point in time I'm not entirely sure why the device isn't outputting audio. We'll get there though.

Keep an eye on the ffado site for any announcements in this regard. You'll probably also be able to pick up the general gist from the svn commit messages. :-)

me to (in the queue)

yes I appreciate that someone is on it,thankyou for being there, although unfortunately this laptop only has usb, so i will not be able to use the fireface 400 with this just my desktop, and of course my mac laptop, I was wondering wether a driver solution for the rme 'babyface' would be easier?
with its usb protocol. Is there any plug and play usb audio hardware available at all? its a bit confusing on the device list .
also i see the firewire motu 896 hd is 'reported to work' does that apply to the older 896 ?.
I hope this last question doesnt come over as sacreligious, but to me Jack is very complicated, i love Ubuntu with the exception of the audio (and scanner) frustrations, would it be conceivable either technically or legally for Ubuntu to adopt Apples Audio protocol, sorry but it is really a great system, imagine if we could use all the hardware available for mac.

Re: me to (in the queue)

In regard to the RME Babyface, this is really outside the scope of FFADO. FFADO is a firewire-only driver framework. The Firewire and USB buses are structured quite differently and one really needs completely different driver approaches for each. As a result, it's unlikely that drivers for USB audio interfaces will find their way into FFADO.

As to the issue of USB audio devices under Linux in general, I understand there are a small number of these supported by the usbaudio driver component of ALSA. By "small number" I mean something of the order of half a dozen or there abouts. Don't quote me on this - this is just a rough feeling I've picked up from lurking on the ALSA lists. The problem, it seems, is that most USB audio devices are not audio-class compliant as defined in the USB spec. Like MOTU and RME have done for firewire, most of the manufacturers of USB audio devices have done things their own way (that's not a criticism since in the case of USB there are certainly very good technical reasons for doing this). This means that specific drivers need to be written for each device, in much the same way as we have for FFADO. This hasn't happened yet, and until it does support for USB audio devices under Linux will continue to be limited.

The MOTU 896HD works very well by all accounts now that the last few issues were sorted out about 6-12 months ago. I don't know about the older 896 - no one to my knowledge has ever tried an older 896 with Linux, so we don't really know. Right at this moment it won't work with FFADO because FFADO doesn't know how to identify this device (I need to see the configROM entries for the device in order to add it to the MOTU device probe code in FFADO). Once that's done it may or may not work - we'd have to suck it and see. I suspect the original 896 may fall into the same device generation as the original 828. That had some quirks and I've added code to work around them but whether that is sufficient for the original 896 as well remains to be seen. In summary it probably won't take a lot of effort to get the original 896 operational, but at a minimum it requires we have someone with that interface who can test FFADO for me. Ideally I need physical access to the device - things move a lot quicker then - but this is often not possible unfortunately.

For the sake of completeness I'll note that the more recent 896 mark 3 is a "generation 3" (G3) device. Support for those is under active development but there's no ETA yet. The development of this support was sped up greatly when someone loaned me an 828mk3. It's had to go back now but hopefully I'll be able to get it back at some stage to finish things off.

MOTU 896

I have a MOTU 896 that I'm having difficulty getting working with FFADO, and would like to offer whatever help I can to get it up and running. Would you want outputs of the various ffado tests? I should note - using ALSA, I was able to record using the mixer, though I have no idea why it worked. It came in as a mono signal, but had a really high DC offset and was terrible quality. During this time, the mixer had all the level meter indicators dancing around as they do when the mixer first powers on; that is to say, the levels being displayed did not correlate with the actual audio signal levels. I've had no real success with JACK. It exits saying:

"Memory locking is unlimited - this is dangerous. You should probably alter the line:
@audio - memlock unlimited
in your /etc/limits.conf to read:
@audio - memlock 762897
no message buffer overruns
JACK compiled with System V SHM support.
loading driver ..
14641403474: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0- built Jun 15 2010 20:11:09
21:35:29.452 Server configuration saved to "/home/brendan/.jackdrc".
21:35:29.456 Statistics reset.
21:35:29.496 Client activated.
21:35:29.554 JACK connection graph change.
14646446496: Error (configrom.cpp)[ 150] initialize: Could not parse config rom of node 0 on port 0
14651490439: Error (configrom.cpp)[ 150] initialize: Could not parse config rom of node 0 on port 0
firewire ERR: Error creating FFADO streaming device
cannot load driver module firewire
no message buffer overruns
cannot continue execution of the processing graph (Broken pipe)"

with the last line repeating a bunch of times. Again, let me know how I can assist with getting this mixer working. I feel like it's not far off from full operation.

Re: MOTU 896

Thanks for your post. Apologies for not noticing it earlier - I missed the initial notification of its posting for some reason.

Firstly, I'm a little confused about your comments regarding ALSA. ALSA will not interface with the MOTU 896 at all so I'm completely mystified how you were able to seemingly record from the MOTU via alsa. It sounds like some kind of analog crosstalk between cables in your rig given your followup comments about the audio quality.

When you talk about how "the mixer had all the level meter indicators dancing", which mixer was this, exactly? ffado-mixer doesn't have level meters.

The jackd output is a little odd, but that might be due to it not running in "verbose" mode. To make any sense of this I really need the output produced when "-v 6" is included on the jackd command line somewhere after the "-d firewire" option.

Speaking of jackd, could you post the exact command line you used to start jackd? This can have a bearing on things. A few other details which would be helpful: the distribution you're running, the kernel (get from the output of "uname -r") and the kind of firewire card you have (get from the information displayed when you run "lspci -v"). Finally, which 896 do you have - the original 896, the 896hd or the 896-mk3?

Voicing support--very interested

I'm an owner of the fireface 800. I think it is a great piece of hardware and would definitely be glad to see it supported in linux. One comment... I would get some mileage out of just being able to control the mixer without booting into Windows, regardless of the audio stream working or not.

Re: Voicing support--very interested

Thanks for your feedback - I'll keep this in mind.

Having said that, I really do want to get at least a proof-of-concept audio streaming system happening sooner rather than later since quite a few people are eagerly waiting for it. The delay has been unfortunate but unavoidable.

long driver development cycle is a problem

I don't mean to be ungrateful, I know you are developing in your spare time and that there is a lot of work to be done. In fact I really want to thank you for doing all this work and offering your findings to the community!
I've been following the ffado development for quite some time now, and a big problem I see is the long development cycle for drivers. In fact it takes so long that many devices are discontinued in production before ffado-support becomes available. This leaves me as a user with a hard decision to make.

As a private person with just a personal, non-profit interest in firewire audio I am not about to go out and spend 1200€ on a firewire audio interface in the hopes that it MIGHT be supported by linux some time in the future. On the other hand, many already supported devices that are of interest to me for my project are really hard to come by, because they are not produced any more and (at least in Germany) there is no market for used studio equipment, because once installed no one ever sells these things again (and additionally I don't really trust second hand hardware).

I'm not here to place blame, I don't really know how to solve this dilemma myself, but it's something that really saddens me, as I was hoping to finally realize my dream of getting a linux box with 36 high-quality, hardware-synchronized audio output channels into my microITX htpc. It's something that I had planned for over 2 years now, and still today it's just not happening :o(

I was originally aiming for the FocusRite Saffire 26/26 for installment, but just before support became available, it was discontinued in favor of the new model. That one is also reported to work, but the channel combination is less useful for my project. Now I am eagerly awaiting support for the RME FireFace 800, and am afraid to experience the same thing again.

I'm a developer myself (though hardware mostly), I know these things take time. However I cannot help being reminded of the SANE project, which basically has the same problem. What use is a really good driver if the device it drives isn't available any more...

Re: long driver development cycle is a problem

I appreciate your sentiments and understand your concerns. It is unfortunate that the driver development for the Fireface 400/800 has dragged on as long as it has. The holdup has been due mostly to "real life" things cropping up and requiring attention. A consequence of this is that I haven't had a great deal of time for FFADO for the past 4 or so months. I'm certainly hoping that this will change soon and it looks like there's every possibility that it will - not only is there RME work to do, but I've been lent a MOTU "mark 3" device to allow me to get a head-start on support for that generation of devices too.

As to identifying the "problem" (such as it is), I think you have pretty well pinned it down - all the FFADO developers are working on the project in their own time. Unlike many higher profile projects under Linux, there are no paid developers - we all have day jobs and/or other activities (eg: university) which necessarily take priority over FFADO work. While some manufacturers (which now happily includes RME) have been supportive of our efforts, to date there hasn't been any case where a company has paid a FFADO developer to work on a driver for their device. The practical upshot of this is that when time pressure comes from other things, often FFADO is one of the first activities to be dropped.

FFADO is certainly not unique in this situation - as you eluded to SANE is another example (although in that case there are at least some currently available scanners for which drivers are available) and there are many others. Unfortunately projects which fill a niche don't attract the same level of funding that higher-profile projects do which means they do tend to develop a lot slower.

On a slightly more technical level, one of the reasons why the RME audio streaming support has been slow to implement is that these devices operate in a rather different way to every other firewire interface we've supported up to now. Fitting this in with the way FFADO operates requires some thinking. We'll get there, and I have a plan of attack in mind, but it's not something which can just be blindly implemented in a few nights of coding and so I don't presently know how far off that will be. As I mentioned earlier, other things have occurred over the last few months which have prevented me personally spending much time on FFADO at all. Things seem to be calming down though so I'm hopeful I can pick up the RME work again soon and make a concerted effort towards getting the audio streaming side of things operational.

There's not much more I can add at this point. I do understand your concerns and share your frustration that things aren't presently moving all that rapidly. Despite the holdups over the last 6 months, I do fully intend to see this thing through. For the reasons stated above however it is not presently possible to give a firm ETA as to when things might be ready for wider testing.


Is ffado any closer to announcing a release date for fireface 400 support?

I Hope

I Hope so!


Re: I Hope

As noted elsewhere on the site I've been a busy with other non-FFADO things over the last few months. Things have settled down again though and I'm starting to be in a position to spend time on FFADO once again. This means that I'll be picking up the FF400/800 development again soon. I apologise for the delay; I had initially hoped to have something functional by now, but when one isn't being paid for this work and has family life to juggle as well things don't always proceed as quickly as one would like.

FFADO RME progress

Not as yet, no. The reality is that I'm working on this in my spare time - I have a day job and a family to look after too. Progress is steady as is evidenced in the changelog but at this point I have no idea when things will start working to the point of being useful for end users.

Having said that, most of the configuration infrastructure is now in place and I'm filling in the connections to userspace on an as-needs basis. Selected controls in ffado-mixer (eg: phantom power) are "connected" already and work as expected. At the moment I'm working on getting the audio data stream working. There are quite a few subtleties about the fireface streaming system which I'm still in the process of trying to understand. Once the issues are understood I'm hoping that audio streaming won't take that long to get going, but at this point I'm not sure how long the "understanding" phase will take.

It is my intention to announce major progress milestones on the FFADO website. Things will also be announced on the ffado-devel mailing list (and maybe on the ffado-users list if it's deemed relevant), and you can follow the bleeding edge progress in the svn trunk log (see the "development" link from the main ffado.org site). If you keep an eye on some or all of these you should stay reasonably up to date with the RME development.

In the queue.

Hi, just wanted to pop my head up to be counted as someone who appreciates your efforts and is also dreaming of the day when this becomes available.

Best of luck. I wish I even understood where to begin!

Re: In the queue.

Thanks for your feedback. It's good to know that the work - once it becomes usable - will be useful to others. :-)