Ticket #317 (closed bug: invalid)

Opened 10 years ago

Last modified 8 years ago

jackdmp+ffado crashes after some time with 2 Saffire Pro 40 daisy-chained

Reported by: orl Assigned to:
Priority: major Milestone: FFADO 2.x
Component: devices/dice Version: FFADO SVN (trunk)
Keywords: daisy-chained Cc:
The device the bug applies to:

Description

Hello,

Since yesterday upgrade, I cannot get jackdmp(or jackdbus)+FFADO running stable with my Saffire Pro 40 daisy-chained. I run the old firewire stack (I couldn't make the new one work until now). Actually, it can run for a long or very short time before problems occur, but it finally fails. Jack logs attached. Please note I just begin with daisy-chain, and I'm not sure whether it's a bug or a bad manipulation coming from me, though it worked perfectly with the previous version of FFADO I used.

Any help appreciated.

Attachments

jack-ffado.log.tar.gz (0.8 kB) - added by orl on 01/09/11 02:24:12.
jackdbus logs
ffado.log.tar.gz (1.2 MB) - added by orl on 01/09/11 12:49:40.
ffadowithunused1.log.tar.gz (1.4 MB) - added by orl on 01/09/11 13:36:57.
ffado logs with the second device sync source set to the first "unused" in the list
ffadowithunused2.log.tar.gz (1.5 MB) - added by orl on 01/09/11 13:38:18.

Change History

01/09/11 02:24:12 changed by orl

  • attachment jack-ffado.log.tar.gz added.

jackdbus logs

01/09/11 12:19:53 changed by arnonym

I assume you have read aggregateDevices and synced your devices accordingly. Either by connecting external adat or spdif and using that as clock-source on one of the devices (the other one is the master and has to be clicked "internal"), or by selecting the "Unused" clock for the slave, which is in fact "sync to firewire".

But that crash looks strange. When the syncing doesn't give the desired results, can you try to get a (short) log with the error by running "jackd -dfirewire <your_options_here> -v6 &> ffadocrash.log" and send that file?

01/09/11 12:49:08 changed by orl

I attach the FFADO logs (-v6).

01/09/11 12:49:40 changed by orl

  • attachment ffado.log.tar.gz added.

01/09/11 13:36:57 changed by orl

  • attachment ffadowithunused1.log.tar.gz added.

ffado logs with the second device sync source set to the first "unused" in the list

01/09/11 13:38:18 changed by orl

  • attachment ffadowithunused2.log.tar.gz added.

01/09/11 13:52:29 changed by orl

I just tried with an ADAT sync. It seemed to work fine, when nothing was launched, but as soon as I run something (like an ardour session which leads to 60% DSP load), Xruns appear, and shortly there after, jack crashes. As I've run this through LADISH, I cannot give you FFADO logs for that attempt. I've read that I should increase the buffers size or number to get it working, but it sounds weird to me, and not really acceptable as it would increase latency.

01/09/11 14:20:59 changed by orl

I did a few checks. Trying to sync on ADAT on the second soundcard, it seemed to work (a bit longer), but finally crashed with a big ardour session (supported with one device). I tried several times, but gives the same result. I've merked that vu-meters of the second cards were blinking a bit before it crashes (kids are sleeping, and no headphone by now, so I can't tell whether the sound seemed unsync).

Then, I've tried something completely desperate, I've plugged the second device directly on the second FW plug of my PCI->FW extension. I then got back to ffado-mixer, and wanted to set the second soundcard to "internal", but -surprise- it was already set to that (though I've checked every time before that it was still on ADAT). So with both cards to "internal", each one on a plug of my FW extension, it works, even with that big ardour session, even when running the transport and reaching limits of DSP load.

I'll check further later. Got to stop for tonight, but I've to say I don't know what to think about this all.

01/10/11 13:29:04 changed by orl

OK, hereis the output of ffado-test ListDevices?, when soundcards are connected to both plugs of FW-PCI adapter and set to "internal" sync.


FFADO test and diagnostic utility Part of the FFADO project -- www.ffado.org Version: 2.999.0-1944 (C) 2008, Daniel Wagner, Pieter Palmers This program comes with ABSOLUTELY NO WARRANTY.


1394 PORT 0

Node id GUID VendorId? ModelId? Vendor - Model

0 0x00130e0401400918 0x0000130E 0x00000005 Focusrite - SAFFIRE_PRO_40 1 0x00130e040140273b 0x0000130E 0x00000005 Focusrite - SAFFIRE_PRO_40 2 0x0000d10080617bf9 0x000000D1 0x00000000 Linux - ohci1394 -

01/10/11 13:54:57 changed by orl

Here the one, when I use one (id finishing by 918) of the two soundcards to "bridge" the second one (id finishing by 273b):

$ ffado-test ListDevices?


FFADO test and diagnostic utility Part of the FFADO project -- www.ffado.org Version: 2.999.0-1944 (C) 2008, Daniel Wagner, Pieter Palmers This program comes with ABSOLUTELY NO WARRANTY.


1394 PORT 0

Node id GUID VendorId? ModelId? Vendor - Model

0 0x00130e040140273b 0x0000130E 0x00000005 Focusrite - SAFFIRE_PRO_40 1 0x00130e0401400918 0x0000130E 0x00000005 Focusrite - SAFFIRE_PRO_40 2 0x0000d10080617bf9 0x000000D1 0x00000000 Linux - ohci1394 -

05/04/12 03:56:50 changed by jwoithe

Evidently there's been little progress with this over the past 6 months. While one would be tempted to ask for a re-test using a more recent svn snapshot I don't expect that will make much difference in this case.

From what I can tell, you reported that when each device was plugged directly into your Firewire card via separate sockets, things worked. Could you describe the bus setup you were using when things did not work in a stable manner? I'm guessing that the second Saffire was plugged into the first Saffire, with that then being connected to the Firewire card in the computer.

At least in theory your initial arrangement (assuming I'm correct about what it was) should have worked. However, there have been numerous comments over the last few years that daisy-chaining like this can give rise to stability problems - not just on Linux, and not just with audio devices. It may be that for some reason or another the Saffire Pro 40 isn't up to the task of passing data from a second Saffire Pro 40 in addition to its own. Or maybe there's a strange behaviour between your firewire card and the daisy-chained audio interfaces. Then again, you mentioned that things worked fine with an earlier version of FFADO, which would normally rule out any hardware-related issue.

On that note, do you happen to recall which version of FFADO was working well with the daisy-chained arrangement?

Beyond that, I note that you mentioned having to run with the old kernel firewire stack. Is it possible to try with the new stack now (and libraw1394 >= 2.0.7), since there's an outside chance that it may be part of the problem.

What do you (Orl) think is the best way to proceed? Should we close this ticket on the assumption that there's a hardware issue at play, or do you want to try to determine what the problem is?

05/04/12 04:00:07 changed by jwoithe

It may also be worth noting that another user reports issues with daisy-chained Saffire interfaces in ticket 333. The circumstances in that ticket are different to the ones described here, but there may be something in common.

06/01/12 05:14:18 changed by jwoithe

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

In the absence of further information I think we have to put this ticket's cause down to a strange hardware interaction. I'll therefore tentatively close the ticket as "invalid" (mainly because none of the other alternatives fit the circumstances any better). If further information comes to hand the ticket can certainly be re-opened to continue the discussion.