Ticket #386 (new bug)

Opened 6 years ago

Last modified 6 years ago

MOTU traveller MK1 not working

Reported by: dsp Assigned to:
Priority: major Milestone:
Component: generic/streaming Version: FFADO 2.1.0
Keywords: Cc:
The device the bug applies to:


Hi, I am running Arch Linux 64bit on a 5.1 MacBookPro?
(05:00.0 FireWire? (IEEE 1394): LSI Corporation FW643 [TrueFire?] PCIe 1394b Controller (rev 06))
is there any chance to get the MOTU Traveller (mk1) working?

FFADO-mixer is working.
when i start jack it runs for about 1 sec and stops again. I can see 22 ins and outs.

- I am aware, that I should not rely on MOTU hardware to work on Linux.
- FW643 rev06 "might cause issues" ??
- I am using FW800 port (tests are with 800-400 cable - some time ago i got similar results with a external harddrive functioning as 800-400 adapter)

any help which direction to go is greatly appreciated. Dominik


ffado-diag.txt (6.4 kB) - added by dsp on 01/06/15 10:29:25.
output of ffado-diag
ffado-test-streaming.txt (3.1 kB) - added by dsp on 01/06/15 10:30:23.
some errors and warnings from ffado-test-streaming
ffado-debug.log (171.5 kB) - added by dsp on 01/09/15 06:31:52.
output of "jackd -dfirewire -p512 -n3 -v6"
ffado-test-streaming-complete.txt (168.1 kB) - added by dsp on 01/09/15 06:53:05.
whole output of ffado-test-streaming

Change History

01/06/15 10:29:25 changed by dsp

  • attachment ffado-diag.txt added.

output of ffado-diag

01/06/15 10:30:23 changed by dsp

  • attachment ffado-test-streaming.txt added.

some errors and warnings from ffado-test-streaming

(follow-up: ↓ 2 ) 01/06/15 14:42:26 changed by jwoithe

Thanks for your report.

My primary test interface for the MOTU driver is the first generation Traveler ("mk 1" if you like, although MOTU didn't use this moniker), and this device continues to work fine for me on my development system. Others have reported similar. I therefore suspect that the difficulties reported here are at least related to other components in the system or the system's setup.

LSI firewire cards have historically been pretty good for audio work, but as you note there are question marks around the older versions (unfortunately there are no further details provided on our host controllers page). This is something to keep in mind.

Although it shouldn't make a lot of difference I will note that there haven't been a large number of FFADO testers running on macbook pro hardware.

The error messages reported in the initial attachment are suggestive of an xrun condition but don't point to a specific cause. Do you always see the same error sequence, or does it vary? In any case, to make any sense of the messages I would need to see the full log trace when running at debug level 6. Please run jackd using something similar to this:

  jackd -dfirewire -p512 -n3 -v6 >& /tmp/ffado-debug.log

Make the contents of ffado-debug.log available and I'll take a look. Could you also describe the parameters you are using when starting jackd?

Having said that, the very first error reported is from getPacket(), complaining that the return value from generateSilentPacketHeader() is invalid. The value returned is 4, which is eCRV_XRun. This is consistent with the latter xrun conclusions so it's probably a reasonable indication as to what's going wrong. The MOTU's transmit streaming object returns eCRV_XRun in one specific circumstance. Short of a bona fide xrun condition it's hard to see how this could be triggered, especially since MOTU start up has been stable for many years. Still, perhaps your system is presenting a corner case which we're not dealing with. The more verbose logs may shed some light on this.

Other random things for you to check on the system:

  • If you have CPU frequency scaling enabled, turn it off and lock your system to the highest clock speed available.
  • Disable wireless networking (if active) and preferably remove the corresponding kernel module.

01/09/15 06:31:52 changed by dsp

  • attachment ffado-debug.log added.

output of "jackd -dfirewire -p512 -n3 -v6"

01/09/15 06:53:05 changed by dsp

  • attachment ffado-test-streaming-complete.txt added.

whole output of ffado-test-streaming

(in reply to: ↑ 1 ; follow-up: ↓ 3 ) 01/09/15 07:03:44 changed by dsp

Thank you very much for taking a look at this!

I uploaded the ffado-debug.log. I also uploaded the complete output of ffado-test-streaming (thanks for showing me ">&")

I usually start jack vie QJackCtl and get same results (behaviour not logs) for all setings I have played with.

While running ffado-test-streaming I could hear some super high tones (a few kHz - estimated)

(in reply to: ↑ 2 ) 01/09/15 07:37:10 changed by dsp

I have now tried running jack server with Frame/Period size=16 and this works.

neither pd nor ardour are capable of running with this small Periodsize. Only programm I have success to play audio at the moment is vlc player.

01/10/15 02:59:03 changed by jwoithe

A few brief thoughts since I'm travelling at present.

The high pitched audio you're hearing indicates that the PC is not supplying audio samples in sync with the Traveler's audio clock. Essentially this means that something has caused FFADO to loose sync with the Traveler. Normally this is caused by something interfering with the scheduling of the FFADO process on the CPU. There are many potential causes of this. The usual suspect is the use of a generic kernel but that's not the problem here since you are running the "low latency" kernel.

Your ffado-diag indicates that the firewire card has its own interrupt, so that eliminates another suspect.

Is there any chance you can test without the proprietary nvidia graphics driver loaded? That has been known to cause trouble before.

It is worth noting that our controller notes suggests that these earlier revision LSI cards may have issues. Until we've eliminated other options we'll just keep that in mind.

The problem appears to be this:

  41649046729: Debug (StreamProcessor.cpp)[ 641] getPacket: dropped packets xrun (37)

That is, we get some dropped packet xruns and this prevents FFADO correctly establishing sync. This is interesting because a user of a completely different audio interface has recently reported the same problem - see ticket:384. That user is using an O2 firewire card and these definitely have shown issues in the past. So we should probably at least contemplate the possibility that the problem for you is the firewire card.

Having jack run at all with frames/period set to 16 is a surprise: without a "realtime patched" kernel I wouldn't have thought it were possible. In any case it is completely understandable that ardour causes the system to fall over at this setting: normally the use of very low settings for frames/period requires a well tuned system.