ProFire Lightbridge

Support Status: 


Even though the BridgeCo press release ( found here) says that this is a BeBoB device, M-Audio Support has said otherwise.

[quote, translated from german]

ProFire Lighbridge can exclusively be used with the firmware developed by M-Audio.

At 30.07.2007 18:41, you wrote:
> To whom it may concern,
> Technical Support wrote:
> > it is correct that the ProFire Lightbridge uses a BridgeCo - Chip.
> > I do not know how well it is supported under Linux though.
> Let me make my question more precise: Does the ProFire Lightbridge use
> a "BeBoB" standard-firmware from BridgeCo or a custom
> development of yours? If the latter should be the case,
> would it be possible to flash a "BeBoB"-compatible version?


your Support Team
M-Audio Deutschland
AVID Technology GmbH

I intend to test one out at a local music store soon, since I think Support may be ignorant of the device's inner workings. I will report on whether this worked out.

Any news on this??

I'll be soon buying this interface, and I'd love to be able to use it in linux... Is there anything I could do to help when I have the lightbridge? Im not a software developer, I have no programming skills but I'd like to help

So it looks like this really is a BeBob device. Discovery works quite right, but I still haven't got streaming to work.

With a little effort we should be able to use this. I'll get back in touch with ppalmers to iron out the issues.

So do you mean it has a standard BeBob firmware?

Some people are having problems due double powering (firewire + PSU) and bad firewire chipsets, will that happen in linux as well?

Just in case it might help, I'm leaving a link to a topic in a pro-audio forum, you may know it already, I'll try to get someone with programing skills and the lightbridge to join the developing effort.. I guess is all I can do at the moment :( looking foward to have it working..

No news for about one year,
has anybody a solution for fhe profire lightbride?
that would be great!
thanks to everybody at ffado... nartu.

After many weeks of frustrating attempts, I have FFADO talking to a Profire Lightbridge.

It seems to only work with kernels 2.6.27 and newer, and with versions of FFADO newer than Release Candidate 1.

My experience, using Ubuntu Intrepid, is that I cannot get xrun-free operation, and the frequency of xruns is the same whether I use a generic kernel or a real-time kernel.

I also experience the sound of dropouts pretty much constantly, but which are not listed as xruns.

I also have not succeeded in capturing audio. All audio inputs are present, but no matter the presence of a signal, they all give just zeros.

Oofus said he had success with this interface, and I want to know what he did different :-) because I have not managed to get this interface to be usable with Linux.

The comments on this page are more than 2 years old, did anyone have any progress with the new FFADO drivers and Linux kernels?

I don't know. Things have gone quiet on the M-Audio front of late. I don't know if it's because none of the developers have M-Audio devices or if we struck a road-block getting information out of M-Audio. I've been concentrating on other devices and haven't really paid any attention to the progress (or lack thereof) in the M-Audio area.

I have received the following devices from M-Audio:
* ProFire 610
* ProFire 2626
* ProjectMix
* Solo

I didn't have the chance to unpack them yet, but that should change in the near future.

This doesn't contain the ProFire Lightbridge. However that device is a fairly standard BeBoB device and should work with FFADO's generic BeBoB support. At least so I've heard.


Of course this is wonderful news, Pieter, at least as it reflects M-Audio's attitude toward ffado. I'm desperately hoping that your work on the Solo might bring us closer to an Ozonic mixer (I recall you suggested some similarity between the devices).

Just yesterday we fired up ffado on my ProFire Lightbridge, and lo and behold, it worked pretty much out of the box.

We didn't do extensive testing, but all channels are listed in JACK, and at least MIDI input and 2 channels of output (to a Behringer DDX3216) seems to fork fine.

As we use the device, I'll report back with more test results.

Which OS and version are you using?
Any further progress to report?

Any news on lightbridge. Can get mine to playback but no record.

Hi all, firstly thanks a lot for your hard work in getting these drivers to us. I have two M-Audio Profire Lightbridge units (got the second one as I thought the first was faulty). I've had to upgrade to the latest ffado driver, jack version and ieee3194 driver to get a stable system (I downloaded the svn sources and compiled on my machine). OS is (Ubuntu studio 12.04 64bit on an HP Elitebook 8440p laptop (intel i5, 8GB mem, hyperthreading on - 4 logical cores, two physical cores). Jack running in real time on the low-latency kernel (default kernel for the distro).
I have a built-in firewire interface on the laptop motherboard (ricoh chipset) and I purchased an expressbus card (TI chipset) as M-audio recommended the TI chipset. Both give the below xrun errors, but the TI chipset unit seems better than the built-in.

Recording software is Ardour.

Problems are many and varied, but here's a list as far as I can remember:

1. Xruns occur on record or playback. Looking at the Jack message window, when jack first starts, no xruns are seen until the recording software is started, after which Xrun messages appear in the Jack message window every few seconds forever after. Recording or playback to multiple tracks (I tried 8, 16 and 32 parallel) seems to have the same frequency of xuns. changing the buffer size and number of buffers per something (can't remember as I don't have the OS booted) seems to have no effect on the frequency of xruns (I'm currently at buffer size of 1024 and number per is 3) - tried various buffer size values from 128 to 2048).

Above behaviour persists regardless of the clock source selected on the M-audio lightbridge unit. I tried internal, S/PDIF and all four of the ADAT interfaces. Clock source definitely changes within the M-audio unit, as it is indicated by an LED on the front panel.

2. Jack only starts once. once it's started, you can't cleanly stop it and it will never start properly again until a reboot.

3. Once Jack is started, the mixer (ffado-mixer dummy) will loose connection with the unit and will never re-connect until reboot, regardless of the condition of Jack (running, killed etc). I had lots of connectivity issues with the mixer until I upgraded everything to latest source versions, as above, where it now seems stable and repeatable. I believe the inability to connect is due to Jack not exiting cleanly and holding some resource locked.

4. The M-audio lightbridge starts up with none of the ADAT interface inputs enabled (probably the cause of some of the comments below regarding playback but no record). With the Windows M-Audio driver applet you can click boxes to enable each interface. The ffado-mixer dummy obviously doesn't have these check boxes, but you can enable each interface by selecting it as the clock source, via the drop-down selection box in the mixer window. Each interface can be selected once; on the second and subsequent attempts (in the ffado-mixer window) a pop-up message informs that the clock frequency couldn't be selected, and the gui drop-down menu remains at the previously selected value. However the M-audio unit does indeed change to the selected input, which is now out of sync with the indication in the mixer drop-down window.

All the above issues can be worked around except the xrun issue, which of course is fatal, as the unit can't be used without clean audio.

Can anyone suggest what could be the cause? I'm happy to lend an M-audio lightbridge unit for development, or carry out testing myself on any new code, if required.

Any logs and diagnostics can be run on request - just tell me what to do and what output to capture.



Computer Consultant, Amateur musician, PA/recording hobbyist

Thanks for your extensive documentation of the problem you're seeing. Apologies for the delay in responding: the spam filter had a false trigger.

Aside from the xruns, the other issues are probably due to missing features (or bugs) in the FFADO driver used by this interface. Obviously to address these we need someone with the interface who can dig into the issues and propose solutions.

In relation to the xrun problem, the first thing to do would be to run ffado-diag and report the output - either here, or to one of our mailing lists (ffado-user or ffado-devel). In many cases it's more convenient to diagnose these problems via email compared to this forum. To capture the output of ffado-diag, run it like this:

ffado-diag > /tmp/ffado-diag.log

You can then post the contents of the file /tmp/ffado-diag.log as you normally would. Obviously the exact location and name of this file is arbitary.

This will allow us to check critical aspects of your machine and make sure that there isn't an obvious configuration problem. We can then proceed as appropriate.

i wanted to let you know that i successfully found the Ins and Outs of the Lightbridge in Jack thru FFADO and was able to listen to Mplayer on the headphone out output36 in the Jack setup and got visual feedback on the Lightbridge LEDs for other channels.
The mplayer playback was flawless, no intermittend stutter, no error messages, nothing.
I will report back later about the other channels, ins and outs, as soon i have time to test.
Best regards,

Hi all,

Wanted to post this information in case it might help someone else trying to have a Lightbridge to work on last Ubuntu Studio release.

For an unknown reason, as a new OS release should enhance things, often in Ubuntu, things that were previously working out-of-the-box, get broken. It's been the case for my ffado driver when switching from Ubuntu Studio 12.10 to 14.04.

Motherboard is a Tyan s2915 (non-E), with two AMD Opteron processors (Texas Instruments TSB43AB22A firewire controller).
As the ffado-mixer worked OOTB on 12.10, on 14.04, it would invariably tell me that no supported device could be found on my system.

I discovered the trick by pure accident while working on the IRQs management on the motherboard, trying to figure out why suspend to ram would always wake up immediately (another thing broken on 14.04).

Enough talking .... what solved the ffado-driver-not-detecting-Lightbridge issue, was to disable irqbalance service at startup.

Operation is quite easy to accomplish : as root, you set parameter "ENABLED" to a value of "0" (zero) within "/etc/default/irqbalance", then you reboot your machine.


I have a working multi-channel audio recording system: Behringer ADA8000s <> M-Audio Profire Lightbridge JACK <> Ardour running on Fedora 19 (with the real-time kernel from CCRMA). I have to use the FFADO mixer trick to get all of the adat ins and outs to work (as described by doughadfield in point 4 of his 10/14/2012 post).

I am trying to separate the gear by using a pair of FireNEX-800 optical repeaters between the Lightbridge and the computer. The computer does not discover the Lightbridge with this set-up. However, if the Newnex repeaters are inserted into the system in place of the firewire cable *after* the link is established, the set-up works. I'd appreciate any suggestions or directions on debugging this situation.

And to all of you dedicated ffado developers and testers, thanks!!!!


Based on what you have written it seems to me that this is more an issue at the firewire bus level than FFADO itself. That is, the use of the optical repeaters on the firewire bus prevent Linux from seeing firewire devices on the far end of the extended bus. In this case, it may be worth posting this to a mailing list to get more specialist assistance. You could try ffado-devel (subscribe first using instructions under "Contact" on our website), since a few of the Linux firewire people keep an eye on that. However, if my understanding of the problem is correct then it's most likely a kernel-level problem, in which case posting to the linux1394-devel list would be best (see

One immediate question: when you talk of a time after the link is established, could you clarify what you mean by "link" and the process you're going through in general?