Ticket #332 (closed bug: worksforme)

Opened 13 years ago

Last modified 12 years ago

FP10 XRuns

Reported by: shuberts Assigned to:
Priority: major Milestone:
Component: generic Version: FFADO 2.0.1
Keywords: ffado, FP10, XRun flood Cc:
The device the bug applies to:

Description

I have a "new-everything" setup which I am tying to use with a Presonus FP10, and am seeing XRuns when recording with Ardour. I sometimes experience a JACK shutdown because of an FFADO assert, and I sometimes see a runaway stream of errors which (even on a four-processor system) almost completely lock the system up.

Here is my ffado-diag output: http://www.pastebay.com/121136 . More info on request.

I do not see these XRuns when recording through an ALSA device (a USB-based Tascam US-122) or through the motherboard sound system.

I have downloaded, compiled, and installed the current stable ffado library, and would be more than happy to cooperate with any investigation or debugging exercises that will help resolve this.

Here is an example failure:

xxxxx@yyyyy:~$ $SHELL -x .jackdrc 2>&1 | tee jackd.log 1 + /usr/bin/jackd -P70 -dfirewire -r96000 -p128 -n3 2 no message buffer overruns 3 no message buffer overruns 4 jackdmp 1.9.6 5 Copyright 2001-2005 Paul Davis and others. 6 Copyright 2004-2010 Grame. 7 jackdmp comes with ABSOLUTELY NO WARRANTY 8 This is free software, and you are welcome to redistribute it 9 under certain conditions; see the file COPYING for details

10 JACK server starting in realtime mode with priority 70 11 00881323442: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0-1983 built Apr 20 2011 22:16:30 12 Unknown destination port in attempted (dis)connection src_name [Hydrogen:out_L] dst_name [alsa_pcm:playback_1] 13 JackEngine::XRun: client = Hydrogen was not run: state = 1 14 JackEngine::XRun: client Hydrogen finished after current callback 15 JackPosixMutex::Unlock res = 1 16 JackAudioDriver::ProcessAsync? Process error 17 JackPosixMutex::Unlock res = 1 18 JackAudioDriver::ProcessAsync?: read error, skip cycle 19 JackPosixMutex::Unlock res = 1 20 JackEngine::XRun: client Hydrogen finished after current callback 21 JackPosixMutex::Unlock res = 1 22 JackPosixMutex::Unlock res = 1 23 JackAudioDriver::ProcessAsync? Process error 24 JackFFADODriver::ffado_driver_wait - unhandled xrun 25 firewire ERR: wait status < 0! (= -1) 26 JackAudioDriver::ProcessAsync?: read error, skip cycle 27 JackFFADODriver::ffado_driver_wait - unhandled xrun 28 firewire ERR: wait status < 0! (= -1) 29 JackAudioDriver::ProcessAsync?: read error, skip cycle 30 JackFFADODriver::ffado_driver_wait - unhandled xrun 31 firewire ERR: wait status < 0! (= -1) (flood of above three lines ensues, locking the machine up)

Given my hardware, I wouldn't expect to see any XRuns at all.

Any help?

Thanks in advance!

Chris

P.S. I posted this to ffado-devel list, but thought that I had ought to post it here.

Change History

04/21/11 19:11:02 changed by shuberts

Sorry about the above! Here is the code-formatted version of the jackd output:

      1 + /usr/bin/jackd -P70 -dfirewire -r96000 -p128 -n3
      2 no message buffer overruns
      3 no message buffer overruns
      4 jackdmp 1.9.6
      5 Copyright 2001-2005 Paul Davis and others.
      6 Copyright 2004-2010 Grame.
      7 jackdmp comes with ABSOLUTELY NO WARRANTY
      8 This is free software, and you are welcome to redistribute it
      9 under certain conditions; see the file COPYING for details
     10 JACK server starting in realtime mode with priority 70
     11 00881323442:  (ffado.cpp)[  92] ffado_streaming_init: libffado 2.999.0-1983 built Apr 20 2011 22:16:30
     12 Unknown destination port in attempted (dis)connection src_name [Hydrogen:out_L] dst_name [alsa_pcm:playback_1]
     13 JackEngine::XRun: client = Hydrogen was not run: state = 1
     14 JackEngine::XRun: client Hydrogen finished after current callback
     15 JackPosixMutex::Unlock res = 1
     16 JackAudioDriver::ProcessAsync Process error
     17 JackPosixMutex::Unlock res = 1
     18 JackAudioDriver::ProcessAsync: read error, skip cycle
     19 JackPosixMutex::Unlock res = 1
     20 JackEngine::XRun: client Hydrogen finished after current callback
     21 JackPosixMutex::Unlock res = 1
     22 JackPosixMutex::Unlock res = 1
     23 JackAudioDriver::ProcessAsync Process error
     24 JackFFADODriver::ffado_driver_wait - unhandled xrun
     25 firewire ERR: wait status < 0! (= -1)
     26 JackAudioDriver::ProcessAsync: read error, skip cycle
     27 JackFFADODriver::ffado_driver_wait - unhandled xrun
     28 firewire ERR: wait status < 0! (= -1)
     29 JackAudioDriver::ProcessAsync: read error, skip cycle
     30 JackFFADODriver::ffado_driver_wait - unhandled xrun
     31 firewire ERR: wait status < 0! (= -1)

...followed by a flood of the last 3 lines, locking the machine.

(follow-up: ↓ 3 ) 04/21/11 20:16:34 changed by audiophyl

  • priority changed from major to minor.
  • type changed from bug to discussion.

I had the same problem. My fix was to install the newest drivers on a Windows machine, connect the FP10, then reconnect it to Linux. Fixed everything.

I'd come across a piece of information indicating that the FP10's firmware was upgraded via the official drivers. That's all I can figure explains the solution.

(in reply to: ↑ 2 ) 04/22/11 20:42:38 changed by shuberts

  • priority changed from minor to major.
  • type changed from discussion to bug.

Replying to audiophyl: Thanks for this tip, audiophyl. I tried doing as you suggested, but sadly, that did not accomplish anything. I retrieved the drivers from Presonus's website, plugged the machine up to a Windows box, and ran the original driver (1.0.0) install followed by the downloaded drivers. Although the installation processes both succeeded, this did not affect the behavior of the FirePod?.

So, sadly, this must go back to being a "Bug". I am also changing the priority to Major, since I cannot use my FirePod? until this is fixed.

I will be happy to work with an FFADO developer to try to resolve this. Both I and my system are ready for any kind of experimentation that would prove useful - including code changes or other detailed investigations.

Thanks!

(follow-up: ↓ 5 ) 04/22/11 21:46:07 changed by audiophyl

Checked your Pastebin. The next thing to tackle is the firewire stack.

Lines 8-16 and 118-123 contain the significant information. You will need to blacklist the following modules:

firewire-ohci firewire-sbp2

And you will need to ensure the following modules are being properly loaded:

ohci1394 raw1394

I have had no luck at all with the new firewire stack, but that's to be expected when you're using experimental software.

(in reply to: ↑ 4 ) 04/23/11 20:02:14 changed by shuberts

Audiophyl - I switched to the old stack and it did not help. I verified through /proc/interrupts, lsmod, and ffado-diag that I was, in fact, using the old stack. I still eventually got a flood of "wait status < 0 (= -1)" errors about 40 minutes into my test session.

Logically, this would implicate either my 1394 card, or the FP10, since we have proven that (1) the problem is not with jackd, since a similar test session works flawlessly for hours using an ALSA (USB) device; (2) the problem is therefore not with any of the other common elements (Ardour, Hydrogen, the kernel other than the Firewire stack, the motherboard, the processor, BIOS settings, etc.)

However, an alternative hypothesis is that both either the old and new stacks, or the old-stack and new-stack libffado, share the same problem that is causing this.

Again, I'm going to offer the general observation that I would be happy to work with an FFADO developer to troubleshoot this problem (if one is reading this).

Thanks again!

Chris

04/23/11 20:26:12 changed by audiophyl

Hold on... 40 minutes in? No problems until then? I have the same setup (2.6.35-28-generic, FP10, but only using the old firewire stack). Give me 40 minutes and I can let you know whether or not it's ffado or your firewire stack. I haven't had any Xrun issues since the Windows driver install.

04/23/11 21:34:24 changed by shuberts

Audiophyl - Sorry, I may have been a little misleading. For one thing, 40 minutes is just an average. It's actually anywhere from 8 minutes to 2 hours. Secondly, there are often "intermediate XRuns" like:

JackEngine::XRun: client = Hydrogen was not run: state = 2
JackPosixMutex::Unlock res = 1
JackPosixMutex::Unlock res = 1
23:21:10.601 XRUN callback (1).
JackPosixMutex::Unlock res = 1
JackPosixMutex::Unlock res = 1
23:21:11.019 XRUN callback (1 skipped).
JackAudioDriver::ProcessAsync: read error, skip cycle
JackPosixMutex::Unlock res = 1
JackPosixMutex::Unlock res = 1

...occurring all along - approximately one every five or so minutes, but sometimes clustering in spates of up to 10.

The 40 minutes is just the "mean time to XRun flood".

However, if you had some tests, I would be happy to give them a try. Fire away!

Thanks again,

Chris

(follow-up: ↓ 9 ) 04/23/11 22:46:57 changed by audiophyl

8 tracks @ 44.1kHz for 50 minutes, 0 Xruns. 8 tracks @ 96kHz for 50 minutes, 8 Xruns.

I still had some software running in the background, so I can't rule that out on the Xruns.

This isn't definitive, but I'd lean toward the firewire card/kernel module (or even the FP10, which would be surprising indeed). I have a modest setup (Ricoh onboard firewire, Lenovo Thinkpad R61), and am using x86_64 Ubuntu as you appear to be. I believe I have an archived session at 96kHz that's just short of two hours with only a handful of Xruns.

Will this problem manifest with only a single track being recorded? Will it manifest at 44.1kHz or 48kHz? What software are you using to record? Are you using FFADO built from current source, or from the Ubuntu repository?

(in reply to: ↑ 8 ) 04/24/11 14:11:11 changed by shuberts

Audiophyl - FYI, I bought this FP10 used, and it had been in production for some time (though on a Windows box).

Plus - more information that I have not yet had a chance to reveal - this FP10 worked almost flawlessly at 96K on an older machine running Ubuntu Studio 10.04. The problems manifested when I switched out my computer's innards - new CPU, MB, RAM, 1394, VDU, HDD, and went to 10.10.

My first attempt to get the FP10 to work after the upgrade featured a Linux install (10.10) with no swap (or rather, only one swap partition on my old drive, now a secondary - an installation error on my part). This installation was extremely unstable: I would start jackd from a terminal window (using compiz), and maximizing the terminal window would blow jack's mind - a flood of "wait status < 0! (= -1)" errors. This led me to suspect that the VDU's interrupt had a higher priority than the 1394's.

I then created a machine with four partitioned installations of Ubuntu Studio: 10.04 32-bit, 10.04 64-bit, 10.10 32-bit, and 10.10 64-bit. In my limited trials, the 32-bit installations were a LOT more stable than the 64-bit, and the 10.04 was more stable than the 10.10. However, I also had created a swap partition on my primary drive, and whether this affected anything or not, the 10.10 64-bit had settled down and was no longer manifesting the fragility described in the previous paragraph.

So, I installed 10.10 64-bit on the machine, and am using the new stack and the latest FFADO library, which is what I am working with now.

As to the other thoughts: Yes, lower sample rates do seem to be more stable. I was running a test at 48K, and it started to spit out the "wait status" failures, but then stopped again after only 20 or so. This was markedly better than the 96K manifestation. As I type this, I am running an Ardour/Hydrogen mix (sourcing Hydrogen into a stereo Ardour record track) which has been going for over 2 hours, and which has had only one XRun (of the "client = ardour was not run: state = 2") variety.

HOWEVER, add to that a sneaking suspicion in my mind that the first run of this mix after reboot always seems the most trouble-prone, and that successive runs seem to be much more stable. And this is a second run.

Finally, although old stack seemed to work better in the 10.04 installations I used, it offers no advantage in the 10.10 setting.

Thinking this around, it seems to me most likely that there is some sort of kernel issue that is either causing the issue or exposing a bug in FFADO or (less likely) in Jack using FFADO.

Would some gdb stack traces help?

Thanks again for all your help.

Chris

(follow-up: ↓ 11 ) 04/24/11 15:34:05 changed by adi

Hi!

For the flooding of driver wait status: this has been addressed in recent versions of jackd2 (it doesn't happen on jackd1). Use 1.9.7 or later.

You mention that 10.04 gives you stable operations while 10.10 miserably fails. I wonder if you're hit by Ubuntu's 10.10 cgroups bug (kernel thing). Your output indicates that you're using RT prios, to the following might not be applicable to you. If you want to be sure, see

http://jackaudio.org/linux_group_sched

for more information. Quick workaround: use a kernel with RT_GROUP_SCHED switched off or follow the instructions how to setup cgroups.

(JFTR, the cgroup thing leads to missing realtime permissions, consequently, FFADO has hard times to deliver the packets at the right time. At least according to your output, you have RT prios, so this isn't the issue at hand here)

Have you tried running FFADO svn HEAD?

(in reply to: ↑ 10 ; follow-up: ↓ 12 ) 04/26/11 11:30:07 changed by shuberts

Hi, Adi,

Per your suggestion, I moved to jackd 1.9.7. Results are preliminary, but this does seem to have cleared up the "flood" part of the wait status floods - though I do still occasionally see a "wait status < 0 " XRun. And, of course, this has done nothing to alleviate the other XRun problems. But it sure will be a relief to not have to deal with the hanging machine problems that go along with those huge message files.

I am using the FFADO trunk, as far as I know. I just did an svn checkout without a revision. Does this get me the head revision?

Thanks for looking in on this!

Chris

(in reply to: ↑ 11 ) 04/26/11 18:19:45 changed by shuberts

Adi,

I just finished another test of 1.9.7 regarding the "wait status < 0" error flood. What happened this time was that I saw all of the usual symptoms of this error except the messages. Specifically, what had always happened in the past was that the transport clock kept rolling, but no further data came to the recording application (Ardour) while the flood of error messages poured out in the message window. Now, there is no flood of error messages (and jackd is easier to kill and terminates on sig 15 in a more orderly way), but it still fell into the state in which the transport clock was running but no data was being sent to Ardour - the "recording head" had stopped moving, even though Ardour had been started in recording mode, and had been recording until the error condition, and the transport clock was still running in Ardour and in qjackctl.

Sorry to not be the bearer of better news. But at least jackd is easier to stop now!

Chris

04/28/11 20:05:13 changed by shuberts

All,

Switched to jackd 0.120.1 and the old stack. Things seem a great deal more stable. I am still seeing the occasional "wait status < 0" XRun - which kills jack with a SIGUSR2 (? what's up with that ?) - and other occasional XRuns. Sadly, though, old JACK plus old stack = lots more stable mix, apparently.

Any thoughts from anyone?

Also, should I take the 11.04 plunge?

04/29/11 00:53:01 changed by autostatic

Hello Christopher, did you try different cables? That helped for me when I started out on my FireWire? + Linux adventure. A decent cable can make a lot of difference! And 0.120.1 is a fairly new JACK1 version. JACK1 is a different implementation of JACK, not an older version compared to JACK2 1.9.7.

Best,

Jeremy

(follow-up: ↓ 16 ) 05/30/11 06:05:31 changed by shuberts

Switched back to Ubuntu Studio 10.04, and all of these problems went away. I am not happy with the older software load, but...

At lease we know that the problem is not with my system. Most likely, it's the new FFADO.

I was kind of hoping that one of the developers would work with me on this bug. I was willing to use my machine as a "test platform" and work with one of the developers in debugging efforts. Unfortunately, my time limit on this expired chasing non-issues instead of working the bugs in the new FFADO.

Guess I'll just wait a year and see if the new FFADO is stable then.

As far as I am concerned, this bug can be closed. I relinquish any interest I have in it.

(in reply to: ↑ 15 ; follow-up: ↓ 17 ) 05/30/11 06:57:19 changed by stefanr

Replying to shuberts:

Switched back to Ubuntu Studio 10.04, and all of these problems went away. I am not happy with the older software load, but... At lease we know that the problem is not with my system. Most likely, it's the new FFADO.

How do you know that?

I was kind of hoping that one of the developers would work with me on this bug.

See comment 11 by Adi on 04/24/11. Unless I am missing something in the follow-up comments, the cgroup scheduling issue has not been pursued. This new kernel feature, as configured in stock Ubuntu 10.10 kernels, is well known to negatively impact audio latency.

(in reply to: ↑ 16 ; follow-up: ↓ 18 ) 05/30/11 07:18:22 changed by shuberts

At lease we know that the problem is not with my system. Most likely, it's the new FFADO.

How do you know that?

Process of elimination. Go back and read through the history of this ticket. Along the way, I swapped out every component. It was only the switch back to 2.0.0 FFADO that really helped my situation.

You may argue, if you like, that the problem was the new Firewire stack. I won't contest it. However, either way, I was able to address the matter by switching back to the old stack in either 10.10 or 10.04. So, FFADO 2.0.1 is clearly implicated.

I would really rather have been having this conversation weeks ago, when I still had the time and inclination to work with you on pinpointing the problem. I would have liked to help make 2.0.1 work right. As it is, I have run out of time. My primary aim is to record and mix music with my Linux system. So, I must grudgingly settle for a software load that I feel to be marginally out-of-date.

I continue to look hopefully toward the future, though, to the day when I can switch to the new stack and use new-stack FFADO without all of these Xruns.

I was kind of hoping that one of the developers would work with me on this bug.

See comment 11 by Adi on 04/24/11. Unless I am missing something in the follow-up comments, the cgroup scheduling issue has not been pursued. This new kernel feature, as configured in stock Ubuntu 10.10 kernels, is well known to negatively impact audio latency.

Read adi's comment again. He says, "At least according to your output, you have RT prios, so this isn't the issue at hand here." The cgroup issue is a non-issue.

Thanks again for the final look-in, but I will just have to let others take the front line on this. As dissatisfied as I am with the older versions of the OS and tools, I can work around it.

I walk away with this understanding: There is a system load which works, so we know that the problem is not in my hardware; the problem lies in the latest software load. Further, older versions of FFADO work much better than the newer ones, regardless of kernel or Jack version. I would think that the FFADO dev team would use this information to spur themselves on to resolve these issues. However, that's really for you to decide.

Best wishes to you. I look forward to the future fruits of your labors.

Sincerely,

Christopher C. Shubert

(in reply to: ↑ 17 ) 05/30/11 13:27:18 changed by stefanr

Replying to shuberts:

At lease we know that the problem is not with my system. Most likely, it's the new FFADO.

How do you know that?

Process of elimination. Go back and read through the history of this ticket. Along the way, I swapped out every component. It was only the switch back to 2.0.0 FFADO that really helped my situation.

I missed that you tried FFADO 2.0.0 on an otherwise stock Ubuntu 10.10.

So, FFADO 2.0.1 is clearly implicated.

If FFADO 2.0.0 <--> 2.0.1 is the only difference between a working and nonworking system, an attempt could be made to narrow it further down by a bisection search between all source revisions between these two. Alas I have no idea how to perform such a bisection with the Subversion client.

I would really rather have been having this conversation weeks ago, when I still had the time and inclination to work with you on pinpointing the problem. I would have liked to help make 2.0.1 work right. As it is, I have run out of time.

OK.

I was kind of hoping that one of the developers would work with me on this bug.

See comment 11 by Adi on 04/24/11. Unless I am missing something in the follow-up comments, the cgroup scheduling issue has not been pursued. This new kernel feature, as configured in stock Ubuntu 10.10 kernels, is well known to negatively impact audio latency.

Read adi's comment again. He says, "At least according to your output, you have RT prios, so this isn't the issue at hand here." The cgroup issue is a non-issue.

I'm not clear about that last conclusion. I don't use cgroups myself, hence don't have first-hand experience. http://trac.jackaudio.org/wiki/Cgroups says that the default Ubuntu 10.10 configuration launches jackd into a group which has zero RT bandwidth budget. The jackaudio.org wiki page goes on to say "In this case jackd can not be started." Does the latter mean that jackd will refuse outright to start because it cannot put itself into the SCHED_FIFO class? Or does it merely mean that jackd will die practically immediately after start because while it actually was able to enter the SCHED_FIFO class it was then preempted by SCHED_OTHER processes anyway because the CPU bandwidth budget was empty?

(follow-up: ↓ 20 ) 06/01/11 12:14:06 changed by audiophyl

I just recently went ahead with the Ubuntu 10.10 64-bit upgrade, and figured I'd note that my FP10 is performing admirably with FFADO directly from the Ubuntu repositories. This reports a version of 2.999.0.

Is there any reason you are unable to use the version of FFADO available from the Ubuntu repositories? If it isn't working properly, I'd suspect your new 1394 (or your VDU stealing priority, as you'd noted earlier).

(in reply to: ↑ 19 ; follow-up: ↓ 21 ) 06/05/11 14:12:01 changed by shuberts

Replying to audiophyl:

I just recently went ahead with the Ubuntu 10.10 64-bit upgrade, and figured I'd note that my FP10 is performing admirably with FFADO directly from the Ubuntu repositories. This reports a version of 2.999.0.

Glad to hear that this is working for you.

Is there any reason you are unable to use the version of FFADO available from the Ubuntu repositories? If it isn't working properly, I'd suspect your new 1394 (or your VDU stealing priority, as you'd noted earlier).

Not likely to be the 1394, as it is working very reliably in the 10.04 setting. Same for the VDU. This is obviously a software problem.

I wish that someone had taken the bull by the horns on this a few weeks back. I was ready and willing to work with a developer at that time (I am a 35+ year programmer with strong skills and experience, including working all the way down to "bare metal"). But I just don't have any more time.

Still, I reckon this will all get worked out in the next few months/year or so, and I will come back around to it then.

For now, I need to stick to using my machine as a production environment.

Best,

Christopher C. Shubert

P.S. As far as I'm concerned, I no longer have any interest in this ticket. Whoever feels empowered may do whatever they feel empowered to do with it!

(in reply to: ↑ 20 ) 06/05/11 14:13:44 changed by shuberts

audiophyl - oh, and I WAS using 2.999.0 svn trunk. My initial log showed that.

06/05/11 15:07:32 changed by arnonym

  • status changed from new to closed.
  • resolution set to worksforme.

Hi Christoph,

your comments are not encouraging but still I will spend some of my private(!) time to deal with this. If you want it to "just work"[tm], please be so kind and make our daily live to "just work" too. The wife and kid like to eat, you know?

Other than that, given the fact that the FP10 is just a name-changed FirePod? and given the fact that the firepod works stable here and with others with all ffado-version since before it was even named ffado (for some even a combination of two or three synced firepods), I suspect that the problem is less on the ffado side and more on your side.

Yes, it would be nice to find out what it actually is. But our time is limited... and we don't (yet) do ffado for a living...

Have fun,

Arnold

PS: I will close this as "WorksForMe?" as this is how it is. It works for me and Christoph seems to have given up on this ticket. If anyone feels like it, he/she can re-open it.

07/14/11 14:24:06 changed by audiophyl

I began to have an XRUN issue, and quickly determined it was tied to heat dissipation and the CPU's ability to change operating frequency. The CPU was rapidly jumping between two frequency settings, causing XRUNs. My solution was to use cpufreq-set to set the operating profile to 'performance' for the duration of my session. That, and clean out the fan.

Just tossing that one out there.

(follow-up: ↓ 25 ) 09/15/11 18:56:01 changed by shuberts

  • status changed from closed to reopened.
  • resolution deleted.

Just thought I would reopen this long enough to point out that I have been running with an older software load (and same hardware as before) just fine, with no Xruns.

Attached is my ffado-diag for my current system.

I am not a heavy user of the system, but have used it for tens of hours of recording and mixdown work, with (as I say,) no Xruns.

Has anything been done to improve the codebase for Juju/FFADO/JACKDMP since June? I really WOULD like to use a later software mix, as some of the features of later revs of Ubuntu Studio are very desirable to me.

Any status on this?

Thanks,

Chris

ffado-diag output:

$ ffado-diag


FFADO diagnostic utility 0.1
============================
(C) 2008 Pieter Palmers


=== CHECK ===
 Base system...
  kernel version............ 2.6.32-33-preempt
FIXME: implement test for RT kernel
   RT patched............... False
  old 1394 stack present.... True
  old 1394 stack loaded..... True
  old 1394 stack active..... True
  new 1394 stack present.... True
  new 1394 stack loaded..... False
  new 1394 stack active..... False
  /dev/raw1394 node present. True
  /dev/raw1394 permissions.. True
 Prerequisites (dynamic at run-time)...
   gcc................ gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
   g++................ g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
   PyQt............... sh: pyuic: not found
   jackd.............. jackd version 0.120.1 tmpdir /dev/shm protocol 24
     path............. /usr/bin/jackd
     flags............  -ljack -lpthread -lrt  
   libraw1394......... 2.0.4
     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.30.0
     flags............ -pthread -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  -pthread -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lgthread-2.0 -lrt -lglib-2.0  
   dbus-1............. 1.2.16
     flags............ -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -L/lib -ldbus-1 -lpthread -lrt  
 Prerequisites (static at compile-time)...
   gcc................ gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
   g++................ g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
   PyQt............... sh: pyuic: not found
   jackd.............. jackd version 0.118.0 tmpdir /dev/shm protocol 24
     path............. /usr/bin/jackd
     flags............ Package jack was not found in the pkg-config search path.
   libraw1394......... 2.0.4
     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.30.0
     flags............ -pthread -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  -pthread -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lgthread-2.0 -lrt -lglib-2.0  
   dbus-1............. 1.2.16
     flags............ -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -L/lib -ldbus-1 -lpthread -lrt  
 Hardware...
   Host controllers:
03:03.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev 80) (prog-if 10)
	Subsystem: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx-
	Latency: 64 (8000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at febff800 (32-bit, non-prefetchable) [size=2K]
	Region 1: I/O ports at e800 [size=128]
	Capabilities: <access denied>
	Kernel driver in use: ohci1394
	Kernel modules: firewire-ohci, ohci1394

   CPU info:
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 920 Processor
stepping	: 2
cpu MHz		: 2800.344
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat
bogomips	: 5600.68
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 920 Processor
stepping	: 2
cpu MHz		: 2800.344
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 4
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat
bogomips	: 5600.38
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor	: 2
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 920 Processor
stepping	: 2
cpu MHz		: 2800.344
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 2
cpu cores	: 4
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat
bogomips	: 5600.35
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 920 Processor
stepping	: 2
cpu MHz		: 2800.344
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat
bogomips	: 5600.36
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

 Configuration...
  IRQ information
Hardware Interrupts:
--------------------
 IRQ    0: PID:  None, count: [132, 132, 132, 132], Sched None (priority None), drivers: ['timer']
 IRQ    1: PID:  None, count: [489, 489, 489, 489], Sched None (priority None), drivers: ['i8042']
 IRQ    4: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['']
 IRQ    7: PID:  None, count:       [1, 1, 1, 1], Sched None (priority None), drivers: ['']
 IRQ    8: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['rtc0']
 IRQ    9: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['acpi']
 IRQ   12: PID:  None, count: [22161, 22161, 22161, 22161], Sched None (priority None), drivers: ['i8042']
 IRQ   14: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['pata_atiixp']
 IRQ   15: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['pata_atiixp']
 IRQ   16: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['ohci_hcd:usb3', 'ohci_hcd:usb4', 'HDA Intel']
 IRQ   17: PID:  None, count: [103, 103, 103, 103], Sched None (priority None), drivers: ['ehci_hcd:usb1']
 IRQ   18: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['ohci_hcd:usb5', 'ohci_hcd:usb6', 'ohci_hcd:usb7', 'radeon']
 IRQ   19: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['ehci_hcd:usb2']
 IRQ   21: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['ohci1394']
 IRQ   22: PID:  None, count:       [0, 0, 0, 0], Sched None (priority None), drivers: ['ahci']
 IRQ   25: PID:  None, count: [71383, 71383, 71383, 71383], Sched None (priority None), drivers: ['eth0']

Software Interrupts:
--------------------


=== REPORT ===
FireWire kernel drivers:
[PASS] Kernel modules present and correctly loaded.
[PASS] /dev/raw1394 node present and accessible.

Here's the jackd console output:

20:53:20.987 Patchbay deactivated.
20:53:20.992 Statistics reset.
20:53:21.017 ALSA connection graph change.
20:53:21.215 ALSA connection change.
20:53:22.987 Startup script...
20:53:22.987 artsshell -q terminate
sh: artsshell: not found
20:53:23.389 Startup script terminated with exit status=32512.
20:53:23.389 JACK is starting...
20:53:23.389 /usr/bin/jackd -dfirewire -r96000 -p128 -n3
20:53:23.391 JACK was started with PID=2281.
jackd 0.120.1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd 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
JACK compiled with System V SHM support.
loading driver ..
libffado 2.0.0 built May  9 2011 20:25:54
20:53:25.421 Server configuration saved to "/home/theshuberts/.jackdrc".
20:53:25.422 Statistics reset.
20:53:25.445 Client activated.
20:53:25.446 JACK connection change.
20:53:25.447 Buffer size change (128).

(in reply to: ↑ 24 ) 09/15/11 19:47:26 changed by jwoithe

Replying to shuberts:

Just thought I would reopen this long enough to point out that I have been running with an older software load (and same hardware as before) just fine, with no Xruns. ... Has anything been done to improve the codebase for Juju/FFADO/JACKDMP since June?

There has been some work but I doubt it is in the areas which will benefit those afflicted by the symptoms described in this ticket. Since June there have been some minor updates to the kernel but I don't *think* your issues were kernel related. Libraw1394 is now at version 2.0.7 and contained a fix for some behaviours which affected DICE-based devices; since your device isn't a DICE device again I suspect this won't change things for you. The only other significant change I am aware of which affects the new stack was made a few days ago - r1995 as described in ticket #306. However, this only affected ffado's behaviour when jackd was exitted so again it seems outside the scope of this present ticket.

So all in all I'm not personally aware of any changes in the last 3 months which would be logically connected to the problem being discussed here. Having said that, it may be worth trying a newer distro with the most recent kernel, ffado and libraw1394 and see if things are any different. Perhaps there is some strange interaction between the PC, the firewire card, the audio interface and the specific software mix on your system which is somehow addressed by these changes. I realise that this is quite a hassle though so understand if you don't wish to go down that route with no guarantee that it will work for you.

Having said all that, I will make note of the fact that I've been running with the new stack now for a few months and haven't had any issues. This is with recent kernels (2.6.38, 3.0.3), libraw1394 2.0.6 and 2.0.7, and jack 0.x.y (ie: not jack2 aka jackdmp). However, the interface is a MOTU Traveler - so it's nothing like yours and therefore my tests do not necessarily reflect the reality for FP10 users such as yourself.

I apologise that I cannot give you a more definite answer.

03/28/12 05:07:50 changed by jwoithe

  • status changed from reopened to closed.
  • resolution set to worksforme.

As noted in comment 22, the general system configuration dealt with in this ticket is working for most people who have tried it, so I'll re-close the bug as "worksforme". The original poster has (understandably) run out of time to pursue this, and without a malfunctioning system it's impossible continue looking for the problem.