MOTU "mark 3" devices

Note that MOTU are hostile to Linux and do not support our effort in any way. If purchasing a new device for use with Linux, please seriously consider purchasing one of the devices marked as having "Full support" on our "Device support" page - this indicates that the vendor is actively helping FFADO in some way.

The "mark 3" MOTU devices released during 2008/9 come with substantial changes to the device control protocol. A picture of this is being built up as owners volunteer information but it's not possible to guess as to when FFADO will function with these devices. The process will be greatly accelerated if someone were to donate (or even loan) a "Mark 3" device to the FFADO project to allow me to analyse the protocol efficiently (please contact jwoithe via the ffado-devel mailing list if you're interested in doing this - I'm in Australia if that helps).

Update, 22 May 2010: I have been loaned an 828mk3 for the last few weeks. It's had to go back now but it's given me enough to start working seriously on the "Mark 3" support and the beginnings of this are in svn (see revisions between r1831 and r1836 for example). It looks like the 828mk3 will be the first "Mark 3" device supported since that's what I've had access to. No ETA on this yet, but progress so far has been good. There's a possibility that I might be able to get the unit back again in a few weeks; if that happens development will possibly come to fruition quicker.

Update, 2 September 2010: audio streaming has been demonstrated on some of these G3 interfaces over the past few months, which means jackd can be used to get audio into and out of these interfaces under certain conditions (when testing this please make sure you're using the most recent svn snapshot available - r1882 or later). There is a report that the Ultralite Mk3 and the Ultralite hybrid (in firewire mode) are mostly working. The 828 Mk3 streams audio for most combinations of optical port mode settings (although some are yet to be tested). The Traveler Mk3 streams audio at all sample rates so long as the optical ports are turned off. Work is continuing on making the optical port support better on the G3 devices which have optical ports. ffado-mixer currently does not work with any G3 models. The protocol is pretty well understood; I'm hoping to find time soon to start adding this to ffado.

Support Status: 



I checked with MOTU support and they (Joseph) said (late Jan 2010):

"MOTU products are not supported with Linux.
While it is unlikely that drivers will be available for Linux in the future, any updates will be announced on

We do not "discourage" anyone from trying to use Linux with MOTU hardware. But these configurations are not supported."

I tried my best to light a fire under them by referring them to your information about other vendors who are supporting you, but only got a "thank you for the information".

This leaves me puzzled about what to do, since I feel the Traveller Mk3 has some excellent features for audio (the hardware limiter, the true portability, and good preamp specs which I've done some checking on). I'd like to leave Mac for Linux and am experimenting with Ardour.

Have you had any takers on loaning you a Mk3? And if/when you do, how sure are you that you could produce usable drivers?


The response you received from MOTU is pretty much par for the course, although it's not as terse as they have been in the past. Perhaps this is a good sign, but obvious any movement is not going to happen in a hurry.

As it turns out, someone has in fact lent me an 828 Mark 3 device - it's sitting just to my right as I type this. I have been able to deduce the protocol for this device without any dramas and at this point I can't see a lot of hurdles preventing support of this in FFADO. I've been a bit pressed for time over the past few months but I'm hoping to be able to get back to FFADO work very soon. In particular I really want to get a skeleton implementation working before the lender of the 828 Mark 3 needs it back.

Based on my experience with the previous MOTU device generation, once the 828 mark 3 is operational I suspect support of the other mark 3 devices won't take a huge amount of effort. As always development for each device will be greatly accelerated if I can get physical access to the interface itself so the request for loan units remains open. Having had access to at least one Mark 3 interface the chances of preliminary "mark 3" support making it into FFADO "soon" have been greatly enhanced. I certainly can't promise rock solid support for other "mark 3" interfaces at this point in time but the chances are good that most features of most of the devices will be usable in due course.

To give you a concrete example, the existing MOTU support was initially developed for the original Traveler (which was of the "mark 2" vintage even though it didn't include this in its name). 828 mark 2 support was almost trivial to add. Ultralite (the original, again a "mark 2" in everything but name) threw a few curveballs at us but we got there in the end. The 896HD also "basically worked", but it included a few unique features which required more extensive analysis to deduce (fortunately an 896HD owner was in a position to do some protocol analysis for me to allow these things to be worked). So once one device of a given generation is working, historically it hasn't been difficult to get at least basic functionality going for others in the same generation.

Had I done a bit more research before purchasing my hardware I would not have chosen MOTU. I like the features, they are a solid piece of gear. But I'm primarily a windows user, and although I didn't plan on using digital performer, I was hoping that the drivers would be solid enough to use. I have found this is not the case.

I own an 896mk3 AND an 8pre and If I were able to I would loan them both to you until you get the drivers working, But I am an audio student and I live in Canada, shipping to Oz would be very cost prohibitive. I'm fairly new to this generation of GNU/Linux and I have very very basic C++ skills, but whatever I can do to help you I will.

I'm running Ubuntu Studio 10.04, but I'm not terribly attached to it, if there is a specific kernel and distro that I could use to help you, let me know. Get in touch with me (you have access to my contact information yes?) and I will bend over backwards to get this up and running. As a Student I can't afford to go out and buy another interface(s) that works.


First up, thanks for your post and I apologise for the delay in getting back to you. Somehow I missed the notification of your message.

Yes, the MOTUs are a decent piece of kit; it's just disappointing that the manufacturer takes such a backward view of Linux users. That said, there's no reason why we can't in time get the mk3 devices working. I now know the basic protocol (thanks to someone lending me an 828mk3 earlier this year) and I have successfully streamed audio to/from this device. It's just a matter of filling in the gaps regarding the other devices in the mk3 family and discovering all their quirks. :-)

I note that you own an 8pre. At least in principle the 8pre should work with ffado - I've had reports from two users that the 8pre driver component works well, at least on their setup. However, to have a working 8pre you do need to run a development snapshot rather than a 2.0.x release. Since the releases are what the distributions tend to ship, one currently has to compile ffado from source to pick up the required changes. I would be happy to talk you through the process - contact me via email and we'll take it from there. You can get my email address from one of my posts to the ffado-devel mailing list. If you have trouble tracking it down, post again here and we'll work something out.

Yes, shipping to Australia from anywhere in the world except other parts of Australia is expensive. :-(

As to the 896mk3, coincidently I was contacted by another owner in the last week also offering to help. At this stage "help" involves compiling snapshots of ffado, testing it, and telling me what breaks. We'll get there though but it may take some time. I would be happy for you to join the test effort as it will help shake down problems quicker. Again, contact me via email and we'll set this up.

In relation to the distribution to use, your existing Ubuntu 10.04 should be fine to base this work on.

Finally, I can't easily get your email address from the website, so pulling my email address out of a ffado-devel post is probably your best bet. To avoid your email getting tied up in my spam filter, please include the project name (ffado) somewhere in the message.

Google led me here. I'm currently using ultralite mk3 with osx over firewire and would like to use it with Ubuntu - so count me in. Please let me know if there's anything what I can do. Unfortunately I'm not familar with c++ or such but I have worked with PHP.


At this stage, probably the best thing to do is to check out the current revision of ffado and try it with your system. There are various articles around about how to do this under Ubuntu, and some of the documents in our "development" section may be useful in this regard. Please post back if you need more detailed information about how to get started.

I have a 2408mk3 (the PCI version not PCIe) and would be more than willing to donate some time to testing. I'm currently using Gentoo but have room for a second OS if you would prefer testing under a different flavor of Linux. If there is anything specific that I can do to contribute other than just using FFADO and communicating bugs and missing/broken functionality please let me know.

Hi xgreenmanx. Welcome, and thanks for your offer to help with testing.

As you mentioned, the interface you have uses the PCI bus to connect to the PC. The PCI bus is a totally different type of interconnect to firewire and has almost nothing in common with firewire. As a result, from the low level driver's point of view PCI (and PCIe) cards are controlled in very different ways to interfaces which connect via firewire.

The drivers the FFADO project works with are for firewire devices, and therefore neither the drivers themselves nor the basic framework provided by FFADO will be of much use when developing a driver a PCI card such as the one you have. For this reason, any driver which might be ultimately developed for the PCI 2408mk3 will not involve FFADO. Most likely it will be a traditional ALSA driver, living alongside drivers for other PCI cards such as the ENS1370, the emu10k1 and ice1712-based cards like the Maudio Delta-1010LT.

For more information about ALSA refer to

In order to develop a driver for the 2408mk3, someone will need the programming specification of that card. This includes details of the control registers, DMA mechanisms and so on. If our experience with their firewire cards is anything to go on it's going to be impossible to get this information out of MOTU, but it's certainly worth trying. Without it, a driver can only be written by someone with a lot of patience and access to hardware and/or software which permits analysis of the PCI bus traffic associated with the card when it's being driven under a "supported" operating system. Even with these resources the exercise would be a lot of work and require much dedication. It is almost certainly a lot more work (and would be more time consuming) than the protocol analysis techniques I used to work out how to control the MOTU firewire devices (being an external bus it's somewhat easier to monitor the traffic than it is on an internal bus like PCI).

I'm sorry I (and the FFADO project generally) can't be of more specific assistance.

If you want further information about any of the things I've raised I would be happy to provide it if I can - just ask.

Just wondering about the progress of this and also how I would get hold of the actual driver.
I have a Motu Traveler MKIII and would love to use Studio 64 for audio work and video production. But its such a pain that its not supported by Motu.

Cool will be great to hear from you...

(ps noob to linux)

Support for the MOTU mark 3 devices is progressing. It's slow for a number of reasons, the most significant being that I don't personally have any mark 3 devices to test code against. The support we do have comes about mostly because I was loaned a mark 3 interface a couple of years ago, and I was able to get the streaming part working on that fairly well. Since then other Mark 3 devices have had their streaming format deduced based on what I discovered from the borrowed interface.

From memory the Traveller mark 3 has been made to work by at least one person. It's been a while since I last worked with the owner of a Traveller Mark 3 (or any other Mark 3 device for that matter) so I'll have to go through my notes to determine exactly what the situation is.

Control of the onboard DSP and mixer of the mark 3 cards is another matter entirely. I do have notes and captures which should allow me to implement this (at least for the interface I'd borrowed) but to date I haven't had a chance to get back to this. This was mostly held up by 2011 being an almost total write-off for me with respect to FFADO (long story), and this year I've been mostly focused on getting existing code into shape in preparation for the release of FFADO version 2.1. I certainly haven't forgotten about it, but I've had to prioritise. Of course, the fact I don't have a Mark 3 interface to test any of this with will make things interesting once I do get to it.

I'll post a followup to this in the next few days once I've had a chance to determine where exactly we're up to with the mark 3 devices in general, and the mark 3 Traveller specifically.

As to where to get hold of the driver, your best bet would be to try our subversion (svn) trunk. There are instructions on how to get hold of this on our development wiki: This is a part of the larger topic about installing FFADO from source ( Let me know if you need any clarifications about this process.

I should also note that we hope to get FFADO 2.1 released in the next few months; that should make it easier for people to get the latest code onto their systems.

I can't promise you that the Traveller mark 3 will work even with the latest code, but it's certainly the version that's most likely to do something. ffado-mixer won't give you anything for the reasons noted above, but running jackd with the firewire driver may work to a degree. In any case, since I don't have a Traveller mark 3 I have to rely on testing done by those who do to let me know where things are at, so any testing you may be willing to do for us would certainly be appreciated.

Hi jwoithe!

I'm completely game to help test as well. I have a MOTU UltraLite mk3 Hybrid and it is the only thing keeping me from moving over to Linux 100%. I'm a professional musician and coder so I'm pretty motivated to get it working.

Let me know if I can help in any way!

Welcome Scott

At least initially, testing your Ultralite Mk3 hybrid with the firewire port and the latest development version of FFADO would be a big help. This way we can confirm the earlier reports that this mostly works. Note that the USB port on this device is not supported by FFADO. Once we know where things stand we can determine the next steps.

The latest code can be obtained from our subversion (aka svn) repository. Instructions for doing so can be found at Additional details about installing FFADO from source can be found at Let me know if you need any details clarified.

Great thanks.

I'm having partial success but seem to be running into a more basic problem in that I can't seem to get jackd working with firewire support. I compiled ffado from source with no problems, then tried compiling jack from source as well with no problems and the --firewire option but running jackd -d firewire only gives me "Unknown driver 'firewire'" Oddly, Qjackctl seems to run and at least try with the firewire driver but then starts everything up with ALSA (or so it seems). Even more weird is when I uninstalled jack completely, Qjackctl seemed to continue to work just fine making me think something is funky. In any case, no sound output from the MOTU.

What is hopeful though is that ffadomixer detects the MOTU just fine and detects sample rate and all that. Not quite sure what I'm doing wrong here. Is this typical?

I agree it seems a bit strange. My immediate suspicion is that you might have two different versions of FFADO installed, except that the jackd you have doesn't appear to have been compiled to include the "firewire" driver. Hmm. What distribution are you running (apologies if you've mentioned this in the past - I can't remember)?

On most distributions, the best way to get an updated FFADO installed is as follows.

  1. Install whichever version of FFADO is supplied by your distribution. This would normally drag in a version of JACK which has been compiled to include FFADO (aka firewire) as a driver.
  2. Obtain the FFADO source code. Include "PREFIX=/usr" as an option to scons when you compile.
  3. Use "scons install" to install the new FFADO over the top of the existing one provided by your distribution.

Doing things this way gives you a new FFADO while keeping your distribution happy.

If you did not include the "PREFIX=/usr" when you compiled, FFADO will be installed in directories under /usr/local/. If your distribution happened to include FFADO then this is how you can end up with two different versions installed.

You mentioned that you compiled JACK; again though, if your distribution provided jack this would be under /usr while by default any new JACK you compile will be installed under /usr/local by default. Normally however JACK would detect the potential for this and warn you at compile time. As for FFADO the way to replace a distribution's JACK installation is to set the prefix to /usr; this is done using something along the lines of "./configure --prefix=/usr" when compiling JACK.

If the above seems to be consistent with what you've done let me know; we'll then have to run a few other commands to determine exactly what is up with your system.


I seemed to have maybe installed with scons at some point without PREFIX=/usr so here's what I did. At some point ffadomixer was seeing the device but now it doesn't but things look much cleaner now.

I removed the libffado references in /usr/local (there were just a few little things in there) and actually I had barely anything in /usr/local so that was pretty easy.

I removed all packages related to jackd using Ubuntu Software Center. I noticed that even when I removed jackd it was still finding jackd. After I uninstalled all things in the Ubuntu Software Center I finally got to a point where jack did not exist on the system anymore. This goes for libffado as well.

When I had a fairly clean looking system devoid of jack and ffado I went ahead and installed all my audio stuff from Ubuntu Software Center. I've been using sudo apt-get install ubuntustudio-audio ubuntustudio-audio-plugins since they are nice packages that I mostly make use of (those are groups of programs). That installed Jack again and also a version of ffado.

Next I compiled ffado from the SVN code using scons PREFIX=/usr to overwrite what is there and then loaded up Qjackctl to try and start up Jack using the firewire driver.

ffadomixer shows the newer icon so I'm thinking that is also updated but ffadomixer does not see the device anymore. I get "logginghandler: Could not communicate with the FFADO DBus service..." which is different from before. Prior to this it would recognize the MOTU and I could change the sample rate and everything. Seemed to be communicating.

QJackctl gives me this error now in Messages:
31mERROR: firewire ERR: Incompatible libffado version! (libffado 2.999.0-2178)[0m
[1m[31mERROR: Cannot initialize driver[0m
[1m[31mERROR: JackServer::Open() failed with -1[0m
[1m[31mERROR: Failed to open server[0m

So I have hope that things are at least different now and I seem to be able to start from a blank slate at least. Any idea why it is reporting that as Incompatible?

Just now I also tried compiling Jack from source (using ./waf configure --prefix /usr --firewire) and then ffado again but got the same results.

Thanks so much for working on this.

oh, just in case it matters. It is jack2 that I am using.

Thanks for the detailed report. There's a few things in there.

Firstly, it does seem like there were potentially multiple versions of FFADO (and maybe even JACK) lying on the system so it's good that that you've resolved that.

The "Could not communicate with the FFADO DBus service..." message tends to indicate that ffado-dbus-server could not be started by ffado-mixer. To work out what might be going wrong here, try running ffado-dbus-server directly from a terminal. If it exits please post the messages it displayed since these might give a clue as to what's going on. If it displays a bunch of stuff and then appears to hang up it's probably working and waiting for something to do; in this case try ffado-mixer again and see what happens.

The "Incompatible libffado version!" message from jackd should not be happening. When you compile ffado it should automatically detect which version of jackd is present on the system and adjust itself to suit. When you run "scons" to compile FFADO it goes through a number of system checks before it starts the compilation. In amongst these should be a series of "checking for" messages related to jack, followed by a summary line (or lines) relating to API versioning. Could you please post all these - I'd like to work out why FFADO's build system is misdetecting the situation on your computer.

Oh hang on: for FFADO's JACK autodetection to work you'll need the jack-devel package installed (the runtime jack package is insufficient). Could you check to see if jack-devel (or a package named long similar lines) is installed? If not, please install it and try compiling FFADO again. Without the jack-devel package it's not possible for FFADO to accurately determine the version of JACK on your system, so (to assist package maintainers) it assumes one which uses the newer FFADO API (to date such a JACK has not been released AFAIK: it's only in the git repository); that's then why you get the incompatiblity message.

Alternatively, you could run "scons ENABLE_SETBUFFERSIZE_API_VER=false". This forces the use of an earlier API regardless of which jackd is on the system. It will result in FFADO using an API which is compatible with the version of jack shipped on your system.

There should be no need to rebuild JACK from source - the version supplied by your distribution clearly included support for the firewire driver, and it will pick up whichever FFADO is installed at runtime.

ok,tried running the ffado-dbus-server manually and got this output (which makes sense I guess):

FFADO Control DBUS service
Part of the FFADO project --
Version: 2.999.0-
(C) 2008, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.

Library version mismatch. (required: libffado 2.999.0-, present: libffado 2.999.0-2178)
Please run this application against the exact corresponding library
it was compiled for. The most common cause for this is having more
than one version of libffado installed.

no message buffer overruns

So I searched apt-cache for jack-dev and found this package: libjack-jackd2-dev
So I did a sudo apt-get install libjack-jackd2-dev and that installed fine.

Then I went to the ffado source and ran this command
which produced this output:
scons: Reading SConscript files ...
Checking for a working C-compiler (cached) yes
Checking for a working C++-compiler (cached) yes
Checking for pkg-config (at least version 0.0.0)... (cached) yes
Checking for jack >= 0.0.0... (cached) yes
Checking for jack < 1.9.0... (cached) no
Checking for jack >= 1.9.9... (cached) yes
Will not report SetBufferSize API version at runtime
Checking for libraw1394 (1.3.0 or higher)... (cached) yes
Checking for libconfig++ (0 or higher)... (cached) yes
Checking for libxml++-2.6 (2.13.0 or higher)... (cached) yes
Checking for libiec61883 (1.1.0 or higher)... (cached) yes
Checking for lrint(3.2) in C library m... (cached) yes
Checking for lrintf(3.2) in C library m... (cached) yes
Checking whether 'which pyuic4' executes (cached) yes
Checking for the python module 'dbus' (cached) yes
Checking for the python module 'PyQt4' (cached) yes
Checking for the python module 'dbus.mainloop.qt' (cached) yes
Checking whether 'xdg-desktop-menu --help' executes (cached) yes
Checking for dbus-1 (1.0 or higher)... (cached) yes
Checking for dbus-c++-1 (0 or higher)... (cached) yes
Checking for alsa (0 or higher)... (cached) no
Checking whether 'which dbusxx-xml2cpp' executes (cached) yes
Checking for variable session_bus_services_dir in package dbus-1... (cached) yes
Trying to find the system triple: (cached) i686-pc-linux-gnu
Doing a DEBUG build
Detected DIST_TARGET = i686
Doing a 32-bit build
Will install the service-file
scons: done reading SConscript files.
scons: Building targets ...
scons: `src' is up to date.
scons: `support' is up to date.
scons: `tests' is up to date.
scons: done building targets

and then of course: sudo scons install

but still seem to be getting the library version mismatch issue.
Earlier I also tried running sudo scons PREFIX=/usr after installing the dev package and got the same result.

It's not possible that I still have two versions of libffado installed is it? I went to /usr/lib and did a ls |grep ffad which returned this:

Wasn't sure if that was two versions potentially so figured I'd post it. But what you're saying seems to maybe be consistent with it looking for library version 2.999.0-.


Thanks for these results. They are interesting.

First let's consider the jack thing. The cached results of the jack tests reported by scons indicate that you have jack2 installed (which is fine). However, it is actually indicating that the version of jack is in fact one which knows about the updated FFADO API. That would be why FFADO activated its new API by default. The mystery now is how you've come to have a version of jackd which reports itself to be version 1.9.9 and yet doesn't know of FFADO's new API. The only thing I can think of is that the jackd on your system isn't a formal release but is instead a snapshot of the development tree (which reports its version to be that which it will ultimately be released as: 1.9.9 in this case). The handling of FFADO's new API was added partway into the development cycle for 1.9.9, so there are certainly some jackd git snapshots which report version 1.9.9 and yet don't have this change. Ordinarily this isn't a problem because production systems wouldn't be running git snapshots. Can you think of any way that such a version of jack could have made it onto your system?

Also, could you run "jackd --version" and report what it says? It'll be interesting to see in the context of the above.

It might be a good idea to completely refresh your FFADO compilation just in case some dependencies have gotten out of whack:

  1. scons -c
    This removes all compiled objects
  2. rm -rf cache
    This kills off all cached information
  3. rm .sconsign.dblite
    This resets the scons system

At this point your ffado source tree is more or less reset to its initial state immediately after checking it out. So now we can try things again: "scons --PREFIX=/usr ENABLE_SETBUFFERSIZE_API_VER=false" (plus any other options to scons you might have used). Note that this won't address the ffado-dbus-server issue: I deal with that next. :-)

The "Library version mismatch" message being displayed by ffado-dbus-server has a completely different root cause to the jackd "incompatible version" message. What it's indicating is that the ffado-dbus-server binary being run is in fact left over from your distribution's FFADO installation. As a result, it's expecting FFADO library from that version (libffado 2.999.0-). However, what it's finding instead is the FFADO library you compiled - libffado 2.999.0-2178. Hense the mismatch. This certainly explains why ffado-mixer doesn't start for you - its attempt to start ffado-dbus-server fails so it fails.

The first thing to do is determine which "ffado-dbus-server" is being run. To do this, type "which ffado-dbus-server" and it'll give the full name and path to the binary that's being run. It will be interesting to see what this returns. The version that should have been installed by your compilation would be in /usr/bin/. Therefore if /usr/bin/ffado-dbus-server is still the old binary it indicates that your compilation and installation of FFADO didn't result in a ffado-dbus-server being compiled and/or installed. Given the output from scons that you posted I don't see any messages indicating that prerequisites were missing so one has to conclude that ffado-dbus-server was in fact compiled. If it was compiled then, it's a complete mystery as to why it wasn't installed.

One thing we can do is confirm whether ffado-dbus-server was compiled. Go to your FFADO source tree and do "ls -l support/dbus/ffado-dbus-server". If this exists it means it was compiled. If it is missing it means it wasn't compiled and we need to work out why.

Regarding the files matching /usr/lib/libffado*, I guess it's possible there's two versions of FFADO floating around. If /usr/lib/libffado2 is in fact a directory then that will probably contain the old FFADO libraries. You could try renaming this (to, for example, old-libffado2) and see if that makes any difference. I don't expect it'll help ffado-dbus-server though because its problem is not the use of old libraries - it's the fact that ffado-dbus-server itself is old. It's easy to do though, so it's worth a shot just in case there's something obscure going on that I've missed.

The other libffado files in /usr/lib/ are probably ok - it's expected that there be three. If you do "ls -lda /usr/lib/libffado*" you'll get date stamps on them, and they should correspond to the date you did the last "scons install". The file is the actual library, while the other two* files are symlinks to

Things are looking a little bit better now! I refreshed the FFADO compilation as you said and it seems like all of that was, in fact, cached. It recognized the right version and I recompiled FFADO.

Now ffado-dbus-server runs and starts to wait for something to happen. When I load up ffado-mixer I get the mixer showing up but in the terminal where I loaded ffado-dbus-server I get a constant stream of this error:

1342160403000194: Error (motu_avdevice.cpp)[2511] ReadRegister: Error doing motu read from register 0xfffff0000b00

On the other hand... QJackCtl seems happy, it allows me to connect a client but I get no audio output from the device other than an occasional loud high frequency pitch coming out of what seems like random channels. QJackCtl also sees all the outputs when I go to the "connect" window.

Ardour won't start at all as it doesn't recognize any devices.

I think we're making progress (albeit rather slowly :-) ).

Regarding the ffado-mixer thing, there's no explicit support for the mark 3 devices at present. Any mixer window which does appear will only include the very basic generic controls. The error about reading from register 0x0b00 is interesting; it tends to indicate that this register doesn't exist in the mark 3 devices. This is curious because that register does in fact exist on these devices. It begs the question why we're getting the error.

When you say there's a constant stream of these errors, how often are they occurring? It is many per second, or only one every second or so? If the latter it would seem that these are associated with the polling of the device for information about the streaming status. It still doesn't explain why there's an error in this context.

Out of interest, do you see the same error when you run jackd?

Those high pitched bursts coming from the unit indicates that the PC hasn't synchronised with the device correctly. There could be a number of causes. The most obvious one is a failure to run jackd with realtime privileges. We can discount this one if your user is in the audio group and the audio group has been granted realtime scheduling permission in etc/.../limits.conf (where ... is determined by your distribution).

Another thing worth checking is your kernel version. Could you please post the output of the "uname -a" command? To reliably run the MOTU devices you really need to be running a so-called "PREEMPT" kernel. Most distributions include such a kernel as an option. Which distribution are you using again?

Finally there could be a bug in FFADO regarding the number of channels active given the device's current configuration. In terms of optical ports and the like could you give me a brief rundown on what's currently active? Given the current setup, how many playback and capture channels would you expect to be active and is this consistent with what jackd is providing?

Sorry for the delay. I teach and our quarter started up so I got wrapped up in that.

I had previously added myself to the audio group but then I found these instructions:
That seemed to indicate that I maybe should have added the 99-realtime.conf file as opposed to other instructions I had previously that told me to edit /etc/security/limits.conf. The limits.d directory did exist on my system so I did what it listed and now I don't receive any errors with ffado-mixer or jackd. Everything seems to look good on there in terms of permissions.

Also, in ffado-mixer I am able to change the sample rate of the mk3 and the device responds which seems like a good sign.

I still get the high pitched tones out of random channels on the mk3 though. And I am also not able to get any sound going through it. No errors or anything, just no sound and random high pitched tones.

I'm running Ubuntu 12.04. Here is the output of uname -a:
Linux scott 3.2.0-26-generic-pae #41-Ubuntu SMP Thu Jun 14 16:45:14 UTC 2012 i686 i686 i386 GNU/Linux

The outputs seem consistent.
8 Analog outs
Main L and R
Phones L and R
SPDIF 1 and 2

The inputs are a little weird.
8 inputs
4 Unknown ins (seems weird although this has DSP on it so maybe its a DSP thing?)
Mix L and Mix R
Reverb 1 and 2
SPDIF 1 and 2


No worries regarding the delay: real life often intervenes in things like this.

I agree that for the moment the realtime scheduling thing is probably sorted. To my knowledge the only change necessary on most distributions is the /etc/security/limits.conf changes (on some systems the file appears as /etc/limits.conf). We'll proceed on the assumption that this is all good.

It is a good sign that ffado-mixer can control the sample rate of the device. It means that this part of the protocol is working correctly for your device.

Given that the scheduling issues are probably sorted, the high-pitched tones are almost certainly due to the MOTU expecting a different number of channels than we're sending. This isn't unexpected: determining the correct layout of the packets being sent to the device is a trial-and-error process which needs to be carried out for each device individually because they are all different.

Oh, at this stage in proceedings we should run with fairly large buffers to minimise issues associated with very low latency operation. What buffer parameters are you using with jackd at present (the "-p" and "-n" parameters after the "-d firewire" option)? For the purposes of our ongoing tests let's start with "-p1024 -n4" since I've found this to be fairly solid with the MOTUs across a wide range of interfaces and computers).

To proceed we need to determine a few details. Firstly, let's stick with your current device configuration to minimise the number of variables. Could you tell me what frequency you were using for this test? We'll stick with that for the moment. Also, could you remind me of which interface you have?

Finally, the presence of the channels labelled as "unknown ins" comes about because according to earlier work there are 4 additional inputs allocated within the incoming packets; it's just that I have no idea what these are yet. It's entirely possible that it's related to the DSP but we lack information to qualify it yet. Note that the "Reverb 1 and 2" channels are (obviously) the output from the onboard reverb DSP unit; whether there are any more remains to be seen.

I'm using a MOTU UltraLite mk3 Hybrid. I've been running it at 48khz sample rate and hooking SuperCollider up to it to do the test (with a 220hz sine tone). Also tried Ardour but Ardour oddly doesn't seem to be finding anything (it used to just see Jack running and hook up to Jack but now it just asks which driver to use... a different problem altogether I assume). Been trying to think of some other programs that would use Jack to eliminate SuperCollider being the element not working. SuperCollider is being shown in the Jack Connections just fine though and works through ALSA/Jack.

I have been running jackd without parameters when running from the command line but in qjackctl I have the "Periods/Buffer" set to 3 and the "Frames/Period" set to 1024. I'm now upping the "Periods/Buffer" to 4 though with the same results.

I also just noticed (not sure if it is important) that when I start jack from qjackctl the MOTU displays a small M on the front of the LCD.

Thanks for the reply.

Regarding supercollider, I think that will be fine for testing. The symptoms you're describing (the high-pitched outputs) don't have anything to do with jack client software; the cause is jackd/ffado not driving the interface in the way it seems to be expecting. The fact that you get these noises as soon as jackd is started indicates it is not due to supercollider misbehaving.

Thanks for confirming the buffer details. 1024/3 should be fine, but let's stick to 1024/4 for now since that's what I've done most of my initial testing with.

The "small M" on the LCD when using qjackctl is certainly interesting (only time will tell whether it's important). Do I take it that this does NOT happen when you run jackd from the command line?

To make it easier to track what's going on it will be easier if you start jackd from the command line for our tests. Something like this should be a good place to start: jackd -P70 -R -dfirewire -p1024 -n4. The "-P70 -R" are probably not needed these days (recent jackd default to realtime scheduling) but for the moment let's leave them in so we know exactly what jackd is doing. Could you try this command and let me know what happens. I fully expect the high pitched noises to still be output, but it provides a solid place to base further testing on.

Over the next few days I will dig up my notes on the hybrid to see what state it was in when we finished up with an earlier tester. In the meantime, could you also post the output from ffado-diag.

Ok, tried it straight from the command line and received identical results including the M.

Also, the high-pitches don't tend to come right when I start Jack in both cases. It takes a few minutes for them to come and they come in and out over time even after stopping Jack. It doesn't seem to start with the high pitches though unless I've started Jack at some point previously.

Just in case it helps... the full output from running jackd -P70 -R -dfirewire -p1024 -n4

jackdmp 1.9.8
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2011 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 70
1342898857998760: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0-2178 built Jul 12 2012 23:00:02
initDirPortGroups(): flags=0x00007071, opta=0xffffffff, optb=0xffffffff
initDirPortGroups(): rxsize=64, txsize=0
initDirPortGroups(): flags=0x00007071, opta=0xffffffff, optb=0xffffffff
initDirPortGroups(): rxsize=64, txsize=52

Thanks for both posts. I'll deal with them together.

Firstly, that "M" in the MOTU display is certainly interesting - although it's good that its appearance is consistent: that should make it easier to track down. When using the interface under a "supported" OS, what would normally appear in the display when sending audio to/from the device?

The full output from jackd seems to confirm that most of the underlying system is fine. Realtime scheduling is being activated, a recent build of FFAOD is in use, the transmit packet size looks sensible (as does receive), and so on. This gives us something solid to build on.

In your second post you noted the lack of a preempt kernel in ffado-diag output. It is not inconceivable that this could be a part of your problem. The MOTU interfaces are very sensitive to interruptions in the data stream being delivered to the device, and the high-pitched sound is a symptom of this happening (although there are other causes). The fact that you don't get the high-pitched noise straight away leads me to think that we ought to look into trying a preempt kernel on your system to see if it provides any improvement.

Besides the generic kernel in use, I don't see anything else in the ffado-diag output which is out of place.

While most distributions ship with a generic kernel, many have a preempt kernel (also referred to as a low latency kernel) in their repository which people can install via the standard package manager. It would be worthwhile looking to see if this is the case for you since it will obviously make it easy for you to install it if so.

Whoops, forgot to post this. I am noticing a lack of preempt kernel:

FFADO diagnostic utility 2.999.0-2178
(C) 2008 Pieter Palmers
2009-2010 Arnold Krille

=== CHECK ===
Base system...
kernel version............ 3.2.0-26-generic-pae
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 251, 0 Jul 21 16:44 /dev/fw0
crw-rw----+ 1 root audio 251, 1 Jul 21 16:44 /dev/fw1
User IDs:
uid=1000(scott) gid=1000(scott) groups=1000(scott),4(adm),24(cdrom),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(lpadmin),124(sambashare),1001(realtime)
Prerequisites (dynamic at run-time)...
gcc ............... gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
g++ ............... g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
PyQt4 (by pyuic4) . Python User Interface Compiler 4.9.1 for Qt version 4.8.1
jackd ............. no message buffer overruns
path ............ /usr/bin/jackd
flags ........... -ljack
libraw1394 ........ 2.0.7
flags ........... -lraw1394
libavc1394 ........ Package libavc1394 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavc1394.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavc1394' found
flags ........... Package libavc1394 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavc1394.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavc1394' found
libiec61883 ....... 1.2.0
flags ........... -liec61883 -lraw1394
libxml++-2.6 ...... 2.34.1
flags ........... -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/i386-linux-gnu/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/i386-linux-gnu/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/i386-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.4.18
flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -ldbus-1 -lpthread -lrt
Prerequisites (static at compile-time)...
gcc ............... gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
g++ ............... g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
PyQt4 (by pyuic4) . Python User Interface Compiler 4.9.1 for Qt version 4.8.1
jackd ............. no message buffer overruns
path ............ /usr/bin/jackd
flags ........... -ljack
libraw1394 ........ 2.0.7
flags ........... -lraw1394
libavc1394 ........ Package libavc1394 was not found in the pkg-config search path.
flags ........... Package libavc1394 was not found in the pkg-config search path.
libiec61883 ....... 1.2.0
flags ........... -liec61883 -lraw1394
libxml++-2.6 ...... 2.34.1
flags ........... -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/i386-linux-gnu/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/i386-linux-gnu/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/i386-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.4.18
flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -ldbus-1 -lpthread -lrt
uname -a...
Linux scott-MacBookPro 3.2.0-26-generic-pae #41-Ubuntu SMP Thu Jun 14 16:45:14 UTC 2012 i686 i686 i386 GNU/Linux
Host controllers:
0d:03.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller [104c:8025] (rev 02) (prog-if 10 [OHCI])
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: i686
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
Vendor ID: GenuineIntel
CPU family: 6
Model: 23
Stepping: 6
CPU MHz: 2400.000
BogoMIPS: 4787.93
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 3072K
IRQ information
Hardware Interrupts:
IRQ 0: PID: None, count: [5362, 7770], Sched None (priority None), drivers: ['timer']
IRQ 8: PID: None, count: [1, 0], Sched None (priority None), drivers: ['rtc0']
IRQ 9: PID: None, count: [246, 247], Sched None (priority None), drivers: ['acpi']
IRQ 16: PID: None, count: [6171, 97], Sched None (priority None), drivers: ['uhci_hcd:usb4', 'uhci_hcd:usb5', 'eth1', 'nvidia']
IRQ 18: PID: None, count: [5623, 4309], Sched None (priority None), drivers: ['ata_piix', 'uhci_hcd:usb6']
IRQ 19: PID: None, count: [21, 23], Sched None (priority None), drivers: ['firewire_ohci']
IRQ 20: PID: None, count: [118, 112], Sched None (priority None), drivers: ['ehci_hcd:usb2', 'uhci_hcd:usb3']
IRQ 21: PID: None, count: [2150, 1079], Sched None (priority None), drivers: ['ata_piix', 'ehci_hcd:usb1', 'uhci_hcd:usb7']
IRQ 40: PID: None, count: [0, 0], Sched None (priority None), drivers: ['PCIe PME', 'pciehp']
IRQ 41: PID: None, count: [0, 0], Sched None (priority None), drivers: ['PCIe PME', 'pciehp']
IRQ 42: PID: None, count: [0, 0], Sched None (priority None), drivers: ['PCIe PME', 'pciehp']
IRQ 43: PID: None, count: [0, 0], Sched None (priority None), drivers: ['PCIe PME', 'pciehp']
IRQ 44: PID: None, count: [0, 0], Sched None (priority None), drivers: ['PCIe PME', 'pciehp']
IRQ 45: PID: None, count: [0, 1], Sched None (priority None), drivers: ['eth0']
IRQ 46: PID: None, count: [232, 162], Sched None (priority None), drivers: ['snd_hda_intel']

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

Great thanks,

I am having some kind of partial success but seem to have some more basic issues that I can't figure out currently. I removed ffado from my system and then successfully compiled from source then went on to compile jack from source as well with the --firewire option. Unfortunately when I try to run jackd -d firewire I'm getting an "Unknown driver 'firewire'" message. Oddly Qjackctl seems to at least try with the firewire option but seems to load ALSA drivers. In any case, there is no sound coming through the MOTU (or from the speakers) when I do that. To make things doubly weird, even when I remove jack completely (and /usr/bin/jackd is no longer existent) Qjackctl is still able to start up jack just fine which makes me think I have something funky going on.

Have you seen this problem by chance?

On the bright side, when I load up ffadomixer it detects the MOTU and is able to pull info off of it (ie. whatever the sample rate is currently set to).


Thanks a lot for working on this. May the schwortz be with you.

I'm a producer working under Windows 7 64bit. I own a MOTU Ultralite MK3 hybrid. But my windows environment is meant only for music production. For every other use you can think of with your computer, I run Ubuntu 12.04.

I was naive when I bought the sound card. Thinking that it is impossible in 2012, that such a prestigious brand of hardware wouldn't be supported under Linux environment. If only I had made some research before...

I wrote to MOTU, asking them what was the reason why they don't release Linux driver. They answered that MOTU management doesn't discus their decision in public.

So here I am, with an awesome and expensive sound card not working 100%, smoking a cigarette. Because I like to smoke after I got F*#@ed.

If I can help, tell me how, Unfortunately, I work on a laptop with no FW connection. So the MOTU is on USB.

Thank you jwoithe
Courage and Strenght!

Thanks for your comments and feedback. Apologies for the delay in responding: the over-zealous spam filter flagged the original post as spam. It's interesting to note that in 2012 MOTU are still pretty much unmoved from the position they took 7 years ago when I first started working to get the original Traveler working under Linux. It's very frustrating.

The status of the Mk3-hybrid is mixed. Earlier reports from owners of this interface leads me to believe that some parts of it are workable using FFADO if the firewire interface is used. DSP control is not, however. At some point I'll add some rudimentary support for the mixer control system used in these so-called generation-3 (G3) devices, but without a device myself testing becomes very hit and miss.

Using the USB interface on the Mk3-hybrid is not currently supported by the FFADO project. Since FFADO focuses on firewire, and because firewire and USB are very different in the way they do things, this is unlikely to change in the foreseeable future. Some other USB interfaces are supported by the ALSA project; however, since MOTU have almost certainly used their own proprietary protocol on USB (as they did on firewire) I can't imagine the USB interface of the Mk3-hybrid will be supported by ALSA soon either.

Obviously we welcome people who can test FFADO with the interfaces they have and report issues they find. However, to do so requires that the firewire interface be used for the reasons noted above.

Hi Guys,

I just found out that there is a touchosc layout for controlling:

Any “mk3” MOTU audio interface
Any “mkII” MOTU audio interface (including
the 896HD, UltraLite, and Traveler)
Tr a c k 1 6
Audio Express and 4pre
MicroBook and MicroBook II
PCI-424 core systems

Which might indicate that cuefx, mix is controlled by sysex or other midi way.

So i someone has the layout you can simply reverse engineer the commands send over midi with a tool like midiox.

Any way thanks a lot for all your effort jwoithe you made me very happy. didn't setup ffado and my Motu Ultralite Mk3 interface yet but i will.

Hope to ditch windoze soon ;)

Kidnest regards,


Edit: it seems like a went to fast:)

The touchosc template is included in the "MOTU Universal Audio Installer" installer.

However i opened them with the touchosc editor and they don't seem to work with midi but some other protocol. the commands are embeded in the touchosc template in a binary format.

So decoding might be harder but not impossible.

kindest regards,


Yes, we're still here. We are however a small group of volunteers who work on FFADO in our spare time. As a result, there can be delays in responding to messages left on the forum. I personally tend to get to the forum about once a week on average.

Based on my experience with an 896-mk3 a while back, I can confirm that cuemix itself controls the mixer using a proprietary protocol over firewire. It is not MIDI. Thanks to a short-term loan of a mk3 device some time ago I have deduced many of the relevant details, but haven't had a chance to do anything with the information yet. The lack of a mk3 device to develop on is another factor in the delay.

I am not familiar with touchosc or the technical details as to how it works. Looking at the PDF you linked to, it seems that touchosc is sending commands via wifi to a computer running the full Cuemix software. Those commands are converted to equivalent firewire commands and then sent on to the MOTU in the usual way. In many respects this makes touchosc a remote control for the Cuemix application running on the PC, rather than for the MOTU hardware itself. Given its name, touchosc probably uses OSC to communicate with the Cuemix application running on the PC.

Capturing the OSC packets sent by touchosc would be relatively straight-forward (or maybe they could be deduced directly from the touchosc template). However, given that OSC operates in a very different way to the firewire bus it's not clear whether the structure of the OSC messages bear any relationship to the commands sent by Cuemix to the MOTU interface via the firewire bus. As a result, the value of this approach is not guaranteed. It would be interesting to see samples of some of the OSC messages as this may allow us to determine whether there is any chance of a degree of similarity. However, I expect in the long run that working directly with the firewire control protocol is likely to be more successful (but I wouldn't mind being proven wrong on this point).

I think i am on the wrong firewire chipset. i run a RT kernel compiled ffado, and jackd al runs just fine. but no sounds is coming out. On win7 if I am on firewire the computer craches after a loud beep comming from the dac. (on usb its less of a problem but still unstable and i have to reboot the card.)
First i upgraded the firmware to 1.06.

Somewhere i found that you can calibrate the motu by twisting a pot inside near the midi connectors.
So later this week i will try calibrating the device.
When i opened the box i found an extra usb connector (female). not sure but i looks to be there for debugging. Can i help the ffado project by sending pics of the pcb and used chips??

The Motu ultralite has 16MB dram and on the pcb there is Copyright by S&S research.
Now its really clear why motu doesn't want to help us. they simply let S&S research Inc build there products. And adding linux support will cost them more money then they will earn from it. :(

Furthermore i found a xilinx sparta xc3s500e FPGA, an
TI floating point DSP TMS320C6722 and an AT91SAM7S256 - Atmel pic, probaly used for the frontpanel (interface and lcd).

Please let me know how i can help the ffadp project.

Kindest regards,


From your description it sounds like there may well be a hardware fault somewhere, especially since you are experiencing difficulties under systems other than Linux. FYI we have had reports of the Ultralite Mk3 working through FFADO for audio streaming. That is, people have successfully used jackd with FFADO to send audio to and from the Ultralite Mk3. We don't currently support the onboard mixer; when running jackd the Ultralite Mk3 will simply run with whatever the power-on mixer setup is.

As a first step in working through your issues you might try a different firewire cable. We have seen some very odd symptoms created by strange cable faults over the years, so this would be a worthwhile exercise if you haven't already tried it.

I am not sure what is being calibrated with the potentiometer that you mention. I would be reluctant to dive in and tweak that unless you are certain of its function.

Regarding the photos of the PCB and the chips used, this won't be of much assistance unfortunately. As you have noted, those chips are mostly programmable and the important details are contained within the firmware that's loaded into them. As it turns out, we do know how to drive the audio side of the mk3 devices. In addition, I do know how to drive the audio streaming side of these interfaces thanks to a short-term loan of an 828mk3. However, I haven't had an opportunity to implement this in FFADO, and the lack of physical access to a mk3 device has been part of the reason this hasn't proceeded. There is someone exploring options in this direction but it will be a little while before we see anything come of this.

Your comments regarding S&S are pretty well spot on: the fact that S&S do all the development work for MOTU means that there's probably no one at MOTU who understands what it is we need and that providing this won't compromise their commercial viability. Approaching S&S is pointless because they would have been told by MOTU to say nothing to anyone. So we have an impasse which is very unlikely to ever be resolved.

As to helping the project, obviously we benefit from ongoing testing by our users because we ourselves do not have many of the devices we are attempting to support. If you have a programming background you might consider getting involved in that side of things. Let us know.


I just wanted to mention that I just got the Ultralite mk3 working with ffado 2.1.9999-2426 on debian Wheezy (3.2.0-4-686-pae).
I'm using vlc through jack which works flawlessly. Many thanks for your efforts despite MOTU's lack of support!


I updated my libffado from svn (libffado-9999-r1 from pro-audio overlay) on gentoo with kernel 3.10.16 and itś still not working on my system.

ffado-mixer shows the device is a Motu_Mark3, doesn't show any fader and if I try to change the sample rate there it says: "could not select ***** as samplerate".

With jack no sound comes out and if I change the sample rate, the sample rate changes on the device but it starts sending high pitched tones and mutes on random channels even if no sound is being sent to jack.

I would love to have this card working on my linux system and am willing to help testing.

There are a lot of variables in play here that we well need to work through. Firstly it would be good to determine precisely which version of ffado is now in use (the version "9999-r1" doesn't bear any obvious resemblance to subversion revision numbers). This version number is probably most easily determined from the output of the "ffado-diag" command.

Another thing to check is to confirm that there are no older ffado library files on the system. Looking under /usr/lib/ you should find only one versioned*.*.* file with a couple of symlinks pointing to it. If there seems to be multiple such libraries present please post the output of "ls -l*".

Regarding ffado-mixer, it is expected that no faders are displayed at present. The hybrid is a so-called "mark 3" device and we do not yet have code to drive the mixer interface of these devices. MOTU completely changed the programming interface in the Mark3 devices and we have not yet had time to add this to FFADO. I deduced most of the details a few years ago when I had a short-term loan of an 828mk3 but time has not allowed me to pursue this further. The lack of physical access to a mark3 device doesn't help. There is now someone starting to take a look at this but there's no ETA unfortunately.

The failure to change the sample rate from ffado-mixer is a little unexpected; I was under the impression that this worked for the hybrid (it was certainly functional on the loaned 828mk3). At this stage I am not sure what to make of this.

I'm not sure what process was being followed in your third paragraph. For instance, were you trying to change the sample rate while jackd was running? Or are you instead referring to the use of jackd with different sample rates?

The high pitched tones you report are typical of what the MOTU interfaces emit when sync is not achieved with the computer or has been lost for some reason. At this stage the reason for this is not clear. One possiblity involves the packets exchanged with the MOTU: either the layout of the incoming packets is not what we expect, or the format of those we're sending to the device is not what it expects. Either of these could give rise to the symptoms you report. These issues crop up if we've guessed the wrong packet formats, for example, and are sending (or expecting) either too few or too many audio channels. Having said that, others have reported the hybrid to be working which suggests that our packet layout must be close to being correct (but this doesn't rule out the possibility that your device is in a mode that no one else happens to have tried until now).

Having said that, there may be other details of your system which prevent FFADO achieving sync with the device. The most probably issue here is the choice of kernel: if running a generic kernel for example, the system can't schedule FFADO with sufficient accuracy to get reliable operation. For most users the fix is to run a "low latency" kernel, which is usually available as a package from your distribution repository. Another option (if very low audio latency operation is targetted) is to run an RT-patched kernel, but this is not necessary for most people.

To try to get a handle on what might be happening it would be good to see the complete output of "ffado-diag" on your system. It might also be easier if you subscribe to the ffado-user mailing list to continue this troubleshooting process from there. Because of the way the forums work with respect to replies it can get awkward to follow ongoing conversations if they become lengthy. In addition, since I only get to check the forums about once a week, replies are usually faster in response to posts to the mailing lists. Information about the mailing lists is in the "Contact" section of the website.


I mainly want to thank you for your efforts in making this card useable! Unfortunately for me my current production computer does not have firewire, so no luck there. This card is what keeps me on Windows now that Bitwig is available for Linux based OS'es.

It'd be appreciated if you'd consider sorting this working on USB as well. I could assist wherever it's possible.


Unfortunately, supporting any USB devices is beyond the scope of the FFADO project. FFADO's entire structure is built around the firewire bus. The USB bus is very different in operation and nature, and it would not be feasible to use FFADO to drive USB devices. From a simplistic point of view, it would be like asking the serial RS232 driver to interface with a thunderbolt device.

The ALSA project has a framework in place for supporting USB audio devices. There are a small number of drivers for specific devices, and the so-called class-compliant driver will work with all interfaces which implement the standard audio class interface. If a USB audio interface is to be supported, it will be through ALSA. Having said that, I think the chances of the MOTU USB interfaces being supported is very small; if their approach to firewire is any guide it is almost certain that they have used a proprietary protocol over USB in order to control their devices, and they will refuse to release the details. They probably don't include a class compliant operation mode. This means that ALSA will only be able to support these interfaces if someone works out how to drive them using protocol analysis techniques - something which is tedious and time consuming. FYI the support for the firewire MOTU interfaces is present in FFADO only because such an exercise was undertaken (by me in the first instance).

I do not have a MOTU interface with a USB port and therefore are not in a position to even contemplate a protocol analysis of such devices. If someone else does and wishes to take this task on in order to write an ALSA driver for the MOTU USB interfaces then that would be great. However, given that it is reasonable well-known that MOTU are extremely hostile toward Linux I would suggest that this has a low probability of occurring - people purchasing audio interfaces for use with Linux these days tend to avoid MOTU for this reason. Of course this doesn't help people such as yourself coming to Linux from other systems with an existing investment in USB hardware, but when choosing to work on drivers for hardware most developers (who are often volunteers) will choose to support the vendors who provide some form of assistance.