Ticket #359 (new bug)

Opened 12 years ago

Last modified 11 years ago

focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode

Reported by: mikkl Assigned to:
Priority: major Milestone: FFADO 2.2
Component: devices/bebob Version: FFADO SVN (trunk)
Keywords: Cc:
The device the bug applies to: focusrite saffire pro 10 i/o

Description

If I want to export a track in e.g. Ardour, jack goes into freewheel mode where the device switches off and then comes back "online" after the export finished.

Short pre-story: When stopping jack, the device's control light normally goes from green to off. After about 10 seconds after that you can hear it's internal relay switch. In these 10 secs, the device may not be switched back on (jack fails to start up). When in freewheel mode, if the export is finished within this period of time (before the device "completely" switched off), the device will come back up (green light back on) and all is well. However, if the time limit is exceeded (relay click) then the device will not get back up running. If you now don't kill jack and try to do s.th. else Ardour (and sometimes the whole desktop) will freeze.

I have attached 2 logfiles with one where the device comes back up after the export (ardour_export_success.log) and in the other it fails because the export is too long (ardour_export_fail.log). I have spotted some lines that correspond to the device completely shutting down (shortly before relay clicks, after ~10secs). They are lines 4229-4231:

1342700844373598: Warning (ieee1394service.cpp)[ 556] readCycleTimerReg: raw1394_read_cycle_timer: Unknown error -1
1342700844373614: Error (CycleTimerHelper.cpp)[ 779] readCycleTimerWithRetry: Could not read cycle timer register
1342700844373618: Error (CycleTimerHelper.cpp)[ 375] Execute: Could not read cycle timer register

These errors do always occur also when the device is normally switched off. After the export when the device should get back up but the device already has completely shut down, the errors in lines 4236-4241 happen:

1342700862331612: Error (ieee1394service.cpp)[1462] allocateIsoChannelCMP: Could not do CMP from FFC0:-1 to FFC1:-1
1342700862331669: Error (avc_avdevice.cpp)[ 816] startStreamByIndex: Could not allocate ISO channel for SP 0
1342700862331688: Warning (devicemanager.cpp)[ 867] startStreamingOnDevice: Could not start stream 0 of device 0x16a5420
1342700862331706: Warning (devicemanager.cpp)[ 904] startStreaming: Could not start streaming on device 0x16a5420!
1342700862331726: Fatal (ffado.cpp)[ 220] ffado_streaming_start: Could not start the streaming system
firewire ERR: Could not start streaming threads
Cannot start driver

So i thought the problem might be somehow related to the way of the device shutting down?

Note: I have tested a Presonus Firepod and different other Alsa devices which all don't experience these problems. I also had the device running on different firewire controllers (VIA, TI, nvidia, ...) but the error is always there. The error also has been around for as long as i have been using the device with ffado now (2-3 years).

Attachments

ffado_diag.log (5.9 kB) - added by mikkl on 07/20/12 03:25:24.
ardour_export_fail.log (297.1 kB) - added by mikkl on 07/20/12 03:26:13.
ardour_export_success.log (0.7 MB) - added by mikkl on 07/20/12 03:26:32.
jack_log (252.1 kB) - added by mikkl on 08/02/12 02:52:33.
selfID_packets_plug.log (2.1 kB) - added by mikkl on 08/14/12 08:54:12.
selfID_packets_export.log (3.0 kB) - added by mikkl on 08/14/12 08:54:35.

Change History

07/20/12 03:25:24 changed by mikkl

  • attachment ffado_diag.log added.

07/20/12 03:26:13 changed by mikkl

  • attachment ardour_export_fail.log added.

07/20/12 03:26:32 changed by mikkl

  • attachment ardour_export_success.log added.

(follow-up: ↓ 4 ) 07/20/12 05:20:51 changed by adi

Which ffado version is this? And more importantly, which exact jackd version do you use?

07/20/12 05:27:29 changed by jwoithe

Thanks for the very detailed report.

As you have observed, the behaviour of FFADO following freewheeling mode does depend on the driver in use (and to a lesser extent on the actual device being used with that driver). At issue is the way different devices respond to having the streaming system shut down and then restarted.

Based on your description, it sounds like the 10 i/o has two different "non-streaming" stages. There's a partial shutdown state which lasts about 10 seconds, during which time the code as it exists at present is able to restart streaming. After this time it seems the device enters some other state which requires pretty much a full re-initialisation before it will come up again.

Within jackd, freewheeling starts with (among other things) a call to the jack_drivers_stop() function, while jack_drivers_start() is called when coming out of freewheeling mode. These lead to ffado_streaming_stop() and ffado_streaming_start() calls respectively in libffado.

The "stop streaming" case eventually leads to the device object's disableStreaming() method as one would expect. For the "start streaming" case, the device's resetForStreaming() method is called prior to enableStreaming(). It is the resetForStreaming() method that is responsible for ensuring the device has been placed in a state which allows streaming to be started.

Your findings tend to suggest that at least in the case of the 10 i/o, resetForStreaming() needs to do more if it finds the device in the "deeper shutdown" state. It would be interesting to know whether this is unique to the 10 i/o or applies to a wider range of the Saffire range.

To resolve this issue we'll need someone with a 10 i/o (and possibly an understanding of the DICE platform) to look into this in more detail. Since I don't have any Saffire devices myself it's almost impossible for me to take a lead in this. Would you (mikkl) be interested and/or able to help?

Hopefully some of the other developers who own Saffire devices will provide feedback as to whether they see similar things.

I'll set the milestone to 2.2 for the moment, but this may be revised if no progress is made in the near-to-medium term future. I'm also setting the component to "devices/dice" since it appears at present that this ticket describes something in terms of that platform.

07/20/12 05:27:44 changed by jwoithe

  • owner changed.
  • component changed from generic to devices/dice.
  • milestone set to FFADO 2.2.

(in reply to: ↑ 1 ) 07/20/12 05:28:48 changed by jwoithe

Replying to adi:

Which ffado version is this? And more importantly, which exact jackd version do you use?

Yes. I wish I knew why under some distributions the svn revision number is stripped off the version reported by ffado-diag.

(follow-up: ↓ 7 ) 07/20/12 06:00:24 changed by mikkl

I'm using a recent development version of jack2 (jackdmp version 1.9.9). From time to time I do updates of the latest snapshot. Same goes for ffado. I'm afraid I cannot tell you the exact revision for either because i'm only getting to the machine once or twice a week, so that will have to wait a couple of days if you really need them. But I can tell you that i've been using recent development snapshots of both ffado and jack over the years and it has always been the same. If i remember correctly this was also the case with jack1 (0.118.0) and any other release of jack (e.g. 1.9.7, 1.9.8) and also before ffado-2.0 with the old firewire stack.

One question: Is this really a dice device? At least 'ffado-dice-firmware' told me that it's not but a BeBob? device.

@jwoithe I'd like to help fixing this. But unfortunately I don't have any understanding of the device yet. What's a bit hindering is the fact that i don't have access to the device 24/7. But maybe i can arrange things so that would not be a real problem.

07/20/12 06:05:10 changed by adi

  • owner changed.
  • component changed from devices/dice to devices/bebob.

Saffire Pro10IO is BeBoB according to the configuration file.

(in reply to: ↑ 5 ; follow-up: ↓ 8 ) 07/20/12 06:09:50 changed by jwoithe

Replying to mikkl:

I'm using a recent development version of jack2 (jackdmp version 1.9.9). From time to time I do updates of the latest snapshot. Same goes for ffado. I'm afraid I cannot tell you the exact revision for either because i'm only getting to the machine once or twice a week, so that will have to wait a couple of days if you really need them.

It would be useful to confirm the FFADO version when you get a chance to do so. That way we all know exactly what code is being used.

One question: Is this really a dice device? At least 'ffado-dice-firmware' told me that it's not but a BeBob? device.

I'm happy to trust ffado-dice-firmware on this. I guessed DICE mainly because most (but not all) of the Saffires are DICE-based. It's my inexperience and unfamiliarity with the Saffire series showing here.

@jwoithe What's a bit hindering is the fact that i don't have access to the device 24/7. But maybe i can arrange things so that would not be a real problem.

Sure. Let's see what surfaces over the next little while and take things from there.

(in reply to: ↑ 7 ) 07/22/12 07:25:43 changed by stefanr

Replying to jwoithe:

Replying to mikkl:

One question: Is this really a dice device? At least 'ffado-dice-firmware' told me that it's not but a BeBob? device.

I'm happy to trust ffado-dice-firmware on this. I guessed DICE mainly because most (but not all) of the Saffires are DICE-based.

The older Saffires are BeBoB based:

  • Saffire (a.k.a. "the white" one or "the original" one)
  • Saffire LE
  • Saffire PRO 26 I/O
  • Saffire PRO 10 I/O

The newer Saffires are DICE based:

  • Saffire PRO 24 and Pro 24 DSP
  • Saffire PRO 40
  • Saffire Liquid Saffire 56
  • Saffire PRO 14

(in reply to: ↑ description ) 07/22/12 07:47:06 changed by stefanr

Replying to mikkl:

1342700844373598: Warning (ieee1394service.cpp)[ 556] readCycleTimerReg: raw1394_read_cycle_timer: Unknown error -1
1342700844373614: Error (CycleTimerHelper.cpp)[ 779] readCycleTimerWithRetry: Could not read cycle timer register
1342700844373618: Error (CycleTimerHelper.cpp)[ 375] Execute: Could not read cycle timer register

These errors do always occur also when the device is normally switched off.

On the old kernel drivers ohci1394 + ieee1394 + raw1394, libraw1394 client programs are required to deal with bus topology changes on there own. (Presumed topology change in your case: Device disappears but hopefully reappears.)

So, if it did not work with the older drivers as you noted, it is a shortcoming in FFADO, although forced onto FFADO due to the ancient low-level libraw1394 API.

On the newer kernel drivers firewire-ohci + firewire-core, the latter associates one and the same /dev/fw* with the same actual node even over topology changes, but there are several flaws:

  • libraw1394 still provides the same old API to its client programs, thus still forces them to deal with topology changes on their own.
  • But libraw1394 has some bugs internally which may cause permanent I/O failures after a topology change.
  • On top of that, if the disappearance and reappearance of a device is badly timed vs. userland holding a /dev/fw* open, I suspect that firewire-core may end up keeping the old /dev/fw* present but nonoperational while creating a new /dev/fw* for the node after its reappearance.

That latter issue would be alleviated if libraw1394 dealt with topology changes properly.

On another note, the FFADO bebob driver and perhaps other AV/C-like drivers as well are somewhat limited in their CMP implementation. Often enough I need to clear CMP state on my BeBoB based device manually (easiest by issuing a bus reset) after unorderly (and maybe also orderly) jackd shutdown before I can start jackd again.

(follow-up: ↓ 11 ) 07/22/12 08:12:32 changed by adi

Would it make sense to keep the streams active? Dry-Running, silence or something like this? It would probably require some changes to jackd, but technically, freewheeling doesn't need to shutdown the driver, it's enough to "ignore what ffado is doing in the meantime".

(in reply to: ↑ 10 ) 07/22/12 16:37:04 changed by jwoithe

Replying to adi:

Would it make sense to keep the streams active? Dry-Running, silence or something like this?

Theoretically yes - it'd be nice to have. I suspect it'd be tricky though, at least for most interfaces. If the streams are still active it means that jack applications will expect the effective processing rate to remain unchanged. However, most drivers rely on the receive stream to set their timing. We'd have to code up something to substitute some other time reference if the interface goes away, and then have some way to smoothly switch back to the interface's timebase when (and if) it returns.

It would probably require some changes to jackd, but technically, freewheeling doesn't need to shutdown the driver, it's enough to "ignore what ffado is doing in the meantime".

When entering freewheeling mode the streaming system is shut down first. It is then explicitly restarted when freewheel mode exits. However in this case there is no need for FFADO (or anything else) to keep a sense of real time; indeed, the whole point is to allow jackd's processing to run as fast as the CPU allows.

In any case there are a number of underlying assumptions made when entering and exiting freewheel mode, which include no change to the device's configuration - something which could quite easily occur across a device power cycle. If we were to ever support transparency across power cycles of the interface we'd probably have to arrange for a full device reset on power-up and the ability to restore the device configuration to its previous state before the streaming system was restarted (not every device powers up in its previous state).

It's not impossible, but it seems like a lot of work to cover a situation which should be fairly rare in the real world. Few people will power their interface off in the middle of a session, if someone powers off while only jackd is still running, is it a major issue if jackd then dies? About the only case I can think of where transparency would be useful is to guard against someone tripping over the interface's power cord in the middle of an active multichannel session in (say) ardour. Jackd will exit and ardour will have issues (saving the session after jack disconnect tends to loose information out about routing from ardour to jack ports).

So in summary, the feature would be good to have but I'm not sure the gains are worth the effort it will take to cover all the corner cases. Then again, if someone were to work on this I'd happily accept the patches. :-)

I should also note that the issue of what jackd/ffado does when the interface is switched off with jackd still active is peripheral to the main subject of this ticket. The primary issue is how the reporter's 10 i/o behaves when freewheeling mode is used, although the similarity in error messages compared to the switch-off-when-active is interesting and possibly gives us a clue as to what might be going on within the interface. In any case, the issue reported with freewheeling mode would be good to fix given that it forms a fairly important part of the Linux audio workflow.

07/23/12 02:34:12 changed by mikkl

Sorry, this may have been a bit unclear when i meant:

These errors do always occur also when the device is normally switched off.

I want to clarify that it actually does not mean that i toggle the power switch. Instead i meant shutting down jackd. Sorry if this has led to confusion so far.

07/24/12 04:23:47 changed by jwoithe

Mikkl: thanks for your clarification in comment 12. It's now much clearer as to why an error was not necessarily expected in this condition.

I'm still not sure why you're seeing those errors, but at least we're not dealing with a device switch-off event.

07/30/12 01:59:15 changed by mikkl

Ok, so am I the only one who is having this issue with this device? Or does no one else have that device for testing? Is there anything I can do to help right now?

(follow-up: ↓ 16 ) 07/30/12 16:35:41 changed by jwoithe

Mikkl: regarding comment 14, it's hard to know: it could be either. Based on your detailed description and the fact that no one else has reported similar problems with BeBob? devices, it seems to me like the pro 10 i/o requires a somewhat different treatment when coming out of freewheel mode than do other BeBob? devices. Whether this is specific to your setup or a more general issue with the 10 i/o is impossible to say: we'd need another 10 i/o user to try the same tests and report back with their findings.

The issue we're seeing seems to be that the 10 i/o de-initialises itself after streaming has been turned off for a certain length of time (around 10 seconds). At this point it would appear that the 10 i/o needs a complete re-initialisation if streaming is to be turned on again. This is in contrast to other interfaces which will remain ready to restart streaming indefinitely in this scenario. I should add here that this is conjecture on my part; I don't have a 10 i/o so I can't investigate the issue in any detail. There may be something important that I'm failing to see.

As far as I know, none of the FFADO developers have a 10 i/o.

To progress this, ideally we'd have things tested by another 10 i/o user to confirm that we are dealing with something that's inherent with this interface. Failing that, we'd probably need someone to dig into the BeBob? driver code and set things up so the 10 i/o (not every BeBob? device is completely re-initialised when coming out of freewheeling mode (which will look like a streaming restart following a streaming shutdown to FFADO). I guess I could have a look at this myself once I have a bit more time (at present I'm concentrating on drivers for devices I have and getting things in place for a release of version 2.1), but this would be a fairly laborious task since I don't have a 10 i/o to test the changes on. If it were to fall to me I suspect it would be sometime after the 2.1 release, so if anyone else could step in to do this it would certainly be welcome.

Having said all that, the failure to read the cycle timer register during streaming shutdown is interesting; I wouldn't want to completely discount that as irrelevant at this stage given that it's happening across a variety of firewire host controllers which includes a TI card. While FFADO does sometimes throw warnings and the like during streaming shutdown as a consequence of subsystems being stopped, a failure to read this register is not normal.

(in reply to: ↑ 15 ) 07/31/12 00:11:58 changed by stefanr

Replying to jwoithe:

the failure to read the cycle timer register during streaming shutdown is interesting; I wouldn't want to completely discount that as irrelevant at this stage given that it's happening across a variety of firewire host controllers which includes a TI card.

As far as libraw1394 and the kernel are concerned, there is only one way how the get-cycle-timer routine can fail: The audio device node has disappeared from the bus.

(follow-up: ↓ 18 ) 07/31/12 05:12:16 changed by jwoithe

Thanks Stefan. That's interesting; if the error message is to be believed this would imply that the device is in fact dropping off the bus when streaming stops. That's rather odd behaviour, but we've seen some very strange things in the past so this would not completely surprise me.

Looking at the code in Ieee1394Service::readCycleTimerReg(), it seems that the return value from raw1394_read_cycle_timer() is being treated as an errno error value, but its documented to be the "error code from the ioctl". A quick glance through the libraw1394 source seems to suggest that a return value of -1 indicates an error from the dispatcher, while fw_read_cycle_timer() does indeed return the ioctl() return value with the code presumedly in errno. In the situation being discussed the return value is -1 as one would expect. To my eyes it therefore seems to me that it is errno which should be reported by Ieee1394Service::readCycleTimerReg() in case of error rather than the return value from this function. Does this seem right to you? On the assumption that it is I've checked in a patch which uses errno as the basis of the error report instead.

Mikkl: if you stop jackd (and get the cycle timer errors with the relay click, etc), are you able to restart jackd at that point, or do you need to powercycle the interface first?

Mikkl: if possible, could you please try svn r2191 and post the cycle timer error messages you get from this version during shutdown? This may at least allow us to confirm the nature of the cycle timer read failure.

(in reply to: ↑ 17 ) 07/31/12 12:09:51 changed by mikkl

Replying to jwoithe:

Mikkl: if you stop jackd (and get the cycle timer errors with the relay click, etc), are you able to restart jackd at that point, or do you need to powercycle the interface first?

The interface can be restarted by jack as soon as the relay has clicked, without a powercycle, but not before that. When doing a powercycle, then there's also a short period of time before which the device cannot be started via jack. But I think that's a different story...

Mikkl: if possible, could you please try svn r2191 and post the cycle timer error messages you get from this version during shutdown? This may at least allow us to confirm the nature of the cycle timer read failure.

I will try that tomorrow!

(follow-up: ↓ 20 ) 08/02/12 02:52:03 changed by mikkl

OK, so here is the log. And the error message suggests that the device indeed dropped off the bus?

1343846915869886: Warning (ieee1394service.cpp)[ 556] readCycleTimerReg: raw1394_read_cycle_timer error: No such device

08/02/12 02:52:33 changed by mikkl

  • attachment jack_log added.

(in reply to: ↑ 19 ) 08/02/12 06:23:18 changed by stefanr

Replying to mikkl:

OK, so here is the log. And the error message suggests that the device indeed dropped off the bus? {{{ 1343846915869886: Warning (ieee1394service.cpp)[ 556] readCycleTimerReg: raw1394_read_cycle_timer error: No such device }}}

Right. An ioctl like the one beneath raw1394_read_cycle_timer returns with "No such device" after

  • firewire-core saw a node either going away from the bus entirely or switching its link layer off (either of which is coupled with a bus reset event),
  • 2 seconds or more since the last bus reset went by (i.e. at least 2 seconds after the bus reset following from the node or its link going off, and at least 2 seconds after any subsequent bus reset which happened during this retaining period),
  • and the node did not come back meanwhile.

This can probably be confirmed by running

echo 2 > /sys/module/firewire_ohci/parameters/debug

as root, then entering the freewheeling mode, and watching the kernel log. This debug flag will cause firewire-ohci to log all SelfID packets. Those packets are broadcast by all nodes (including the local node) after each successfully completed bus reset. SelfID packets are small packets in which is encoded what physical ports exist and and are connected on each node, and whether each node's link is on or off.

For comparison you could also just plug in and plug out the device while this firewire-ohci debug flag is set, and watch the SelfID packets that are associated with these events respectively. I find "sudo tail -f /var/log/messages" to be a convenient way to watch syslog messages as they happen. (Many but not all distributions use /var/log/messages also for kernel messages, besides miscellaneous system messages.)

08/06/12 08:32:40 changed by mikkl

OK, i will have a look at the packets, too. But this will have to wait some time now. I'm off for about 10 days so i won't have the chance to look after the device.

08/06/12 16:26:53 changed by jwoithe

Mikkl: no problem. Enjoy your time away and we'll catch up when you get back.

Referring back to comment 19 (which I meant to respond to earlier), having the device drop off the bus just because streaming is turned off seems really odd. It would be good if some other 10 i/o owner could check this to see if it is a property of these interfaces or is something specific to Mikkl's unit (or something else specific to his setup). However, I don't think we have another such user following development, so we probably have to push ahead with Stefan's suggestions and see what we turn up.

I should also add that since the same error is reported when jackd is shut down normally (Mikkl: correct me if I'm wrong here), it seems this "drop off the bus" trick is triggered by the action of turning the streaming off, as opposed to it being linked specifically to free-wheeling mode.

08/14/12 08:53:48 changed by mikkl

I have attached two logs: One for plugging the device in and out and another one when exporting. I also have the device at my place now so i could do some more testing and more frequently. Hit me!

08/14/12 08:54:12 changed by mikkl

  • attachment selfID_packets_plug.log added.

08/14/12 08:54:35 changed by mikkl

  • attachment selfID_packets_export.log added.

08/24/12 04:28:45 changed by jwoithe

Sorry for the long delay Mikkl. Thanks for the two logs which I think pretty much confirm the hypothesis we were kicking around a few weeks ago.

In the first log we note that

selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci

is indicative of of an "unplug" event, while

created device fw2: GUID 00130e010006078d, S400

is a nice easy to see tracer for a device coming back onto the bus.

If we now look at the "export" log we first of all see

selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci

fairly early on, which pretty much confirms that the device drops off the bus as if it were unplugged. Around 4 seconds later we see the "created device fw2: GUID 00130e010006078d" entry which indicates that the device has reappeared on the bus.

Based on this, it appears that the pro 10 i/o drops itself off the firewire bus when the streaming system has been idle for a certain period of time (around 10 or so seconds based on earlier comments). It then appears back on the bus within a short period of time, but by then FFADO would have exitted since the device it was communicating with disappeared. Even if FFADO didn't exit I think it would be rather difficult to arrange for it to hang around in the event of a disappearing device on the off chance it reappears again. The general case will be hard to get right because there's no guarantee that the bus arrangements will be the same when the device reappears, nor is it possible to assume anything about the device's state.

What I can't explain is why this interface does this (no other interface behaves this way to my knowledge). Plus we don't currently know whether it's just your particular pro 10 i/o or if they all do this odd-ball thing.

So, where can we go from here? To anything running on the computer this behaviour is indistinguishable from pulling the cable out and plugging it back in 4 seconds later. In the event of a disappearing device one's immediate reaction would normally be for FFADO to quit since there's nothing sensible it can really do. But then we have the Pro 10 i/o which seems to almost reset itself when the streaming goes idle. I really don't know how we could begin to accommodate this into the future.

About the only possible approach which comes to mind is to modify the FFADO JACK driver so that when entering freewheeling mode we keep streaming going, sending zeros to the device and dropping all data coming from the device. I'd have to study JACK in more detail to determine whether this was possible though: there is still a need to process data for the device, and I'm not sure the driver run cycle functions are called during free-wheeling mode. Given that the whole point of free-wheeling mode is to run independently of the hardware, I strongly suspect there will be difficulties here. But I could be wrong: I'm not a JACK expert.

What say others?

09/13/12 02:06:24 changed by mikkl

No problem. So, given that i'm the only one with this device and problem (which we don't really know if it's normal for the device) the whole thing looks like much effort to fix? Maybe I should just drop the device, haha.

I have heard something from the Ardour guys that they think about a non-freewheeling export mode which could possibly circumvent my problem (see here). But it does not seem trivial and whether and when this will come is not clear.

09/13/12 03:29:10 changed by jwoithe

So, given that i'm the only one with this device and problem (which we don't really know if it's normal for the device) the whole thing looks like much effort to fix?

It's certainly not too much effort to fix: I would dearly like to identify the true problem and - if it's related to the way FFADO does things - fix it. The problem is one of logistics; as you say, at this stage it looks like you're the only one using a Pro 10 i/o. Irrespective of whether the issue you're seeing is unique to your particular interface, the coding of a workaround can only really be done by someone who has the device because testing requires that device (no other interfaces are showing these symptoms). Unfortunately this means that if you're not in a position to undertake this task we'll have to wait for a Pro 10 i/o owner who is.

... they think about a non-freewheeling export mode which could possibly circumvent my problem ...

Yes, that would work around your immediate problem but like you said it may not happen for a while. Another alternative is that you do your main work in Ardour with the Pro 10 i/o. When you're ready to export you close Ardour/jack, restart jack against any ALSA card (eg: your mainboard audio interface), run Ardour and do your export. It's messy (and you could encounter complications due to the changing number of channels seen by the Ardour session) but it may work for you.

09/20/12 02:28:47 changed by mikkl

When you're ready to export you close Ardour/jack, restart jack against any ALSA card [...]

Yop, I have already accustomed to that workaround. And yes, it's messy when you aren't careful your channels configuration gets purged from the session. So it's not really an option if other people except me want to do a export. So a fix would really be great!

Irrespective of whether the issue you're seeing is unique to your particular interface, the coding of a workaround can only really be done by someone who has the device [...]

So because I'm the only one with a device right now I would gladly like to help. And if it's not too much effort like you said then maybe I could try for myself. I have some experience in hardware programming. However, I'm not yet familiar with the ieee1394 and ffado stuff but with your previous comments I could get a rough idea what's happening.

10/30/12 04:38:10 changed by jwoithe

Mikkl: The next step with this issue is to determine whether this is an issue only with your particular hardware set or if it affects all Pro10 users. To this end we really require someone else with a Pro10 to test their interface and see if they observe the same trouble as you do. If they do then it pretty much guarantees that there is an issue within the device which we will have to work around in some way. However, if it cannot be reproducible it suggests that the cause is something specific to your setup. Obviously the approach to debugging the problem will vary greatly depending on what the situation is.

(follow-ups: ↓ 30 ↓ 31 ) 10/30/12 08:10:23 changed by sekisushai

Hello, I've got a saffire pro 10 i/o and i can't run it anymore with ffado and jackd. I've got the same kind of behaviour (the devices turns off when I try to launch jackd) and the same kind of errors. I'm happy to test whatever you want to help sorting theses things out. I'm pretty a newbie with debbuging theses kind of stuffs so you'll have to help me. I don't exactly understand what is the jackd freewheeling mode.. ? I've got some logs here : http://sekisushai.free.fr/ffado/ Pierre

(in reply to: ↑ 29 ; follow-up: ↓ 32 ) 10/30/12 14:09:49 changed by stefanr

Replying to sekisushai:

I've got a saffire pro 10 i/o and i can't run it anymore with ffado and jackd. I've got the same kind of behaviour (the devices turns off when I try to launch jackd) and the same kind of errors. I'm happy to test whatever you want to help sorting theses things out.

The final failure is the same (ENODEV in readCycleTimerReg), but the events which lead up to this are different: For mikkl, it only happens when entering freewheeling mode. For sekisushai, it happens immediately at the start before the streaming system can really get into gear. sekisushai has got an O2Micro OHCI-1394 controller which is known to be troublesome at least from older experiences. (See the wiki page on HostControllers.) Maybe FFADO needs a longer than usual time on the O2Micro controller to bring the streams up, and the Saffire PRO 10 I/O decides to play its auto-switch-off game due to that.

(Meta comment: It is a pity that Trac, like some other bug trackers, apparently does not support splitting of one ticket into two. This is one of the reasons why bug trackers are not a good tool for bug reporting. At least reporters should better always open new bugs rather than appending to existing ones: Joining of duplicate bugs into one ticket is at least somewhat supported by Trac and other trackers, unlike splitting of unrelated bugs into two tickets.)

(in reply to: ↑ 29 ) 10/31/12 03:32:39 changed by jwoithe

Replying to sekisushai:

I don't exactly understand what is the jackd freewheeling mode.. ?

Freewheeling mode is where jackd runs as fast as it possibly can: it doesn't simply process audio at the audio sampling rate. Freewheeling is used when doing an export from Ardour for example: since there's no need to play the final audio (it's being written to a file instead) there is no reason why the audio can't be processed faster than real time.

(in reply to: ↑ 30 ) 10/31/12 03:41:30 changed by jwoithe

Replying to stefanr:

The final failure is the same (ENODEV in readCycleTimerReg), but the events which lead up to this are different: For mikkl, it only happens when entering freewheeling mode. For sekisushai, it happens immediately at the start before the streaming system can really get into gear.

Agreed. However, the report from sekisushai does lend weight to the idea that there's something about the timing of operations with the Pro10 that we are not aware of.

Maybe FFADO needs a longer than usual time on the O2Micro controller to bring the streams up, and the Saffire PRO 10 I/O decides to play its auto-switch-off game due to that.

It could be, but I'm not overly familiar with the O2Micro controller or its foibles so I'm not certain there's an obvious mechanism which would cause FFADO to take so much longer to get things going when this controller is in use.

Meta comment: It is a pity that Trac, like some other bug trackers, apparently does not support splitting of one ticket into two.

That would be a handy feature from time to time. Having said that, I'm not yet convinced that these two reports don't have a common fundamental cause. Identifying it though is going to be challenging.

10/31/12 05:50:55 changed by mikkl

The final failure is the same (ENODEV in readCycleTimerReg), but the events which lead up to this are different: For mikkl, it only happens when entering freewheeling mode. For sekisushai, it happens immediately at the start before the streaming system can really get into gear.

I think that in my case the readCycleTimerReg error is the final result of the device shutting down ~10 seconds after having entered freewheeling mode (relay click, green light off) and this also happens when "normally" shutting down jack. Remember that I can enter freewheeling mode and successfully restart streaming without the error when the time interval to do that is short enough. I seems more like it's not the cause of the problem (device dropping off the bus) but a symptome.

(follow-up: ↓ 35 ) 04/17/13 21:54:30 changed by rgreen

I've experienced this same problem. I start an export in Ardour while jack is running on my saffire pro26IO (the PRO10's big brother, another BeBob? device). The interface flashes its power and channel peak lights soon after the export begins, and when the export completes, ardour complains that it has lost its connection to jack and locks up solid.

If this is related to 'freewheeling mode' as you say, then I think it's a problem with Ardour, not ffado or jack. If Ardour wants to go 'off clock' and process its data files faster (or slower), then it should be on it to disconnect or ignore the streams. Jack is a sound server, and once running, should keep going to serve all of its connected applications. Why should a single application have the authority to put the server in a mode that would pull the rug out from under all other connected applications???

(in reply to: ↑ 34 ) 04/21/13 01:45:38 changed by jwoithe

Replying to rgreen:

I've experienced this same problem. I start an export in Ardour while jack is running on my saffire pro26IO (the PRO10's big brother, another BeBob? device). The interface flashes its power and channel peak lights soon after the export begins, and when the export completes, ardour complains that it has lost its connection to jack and locks up solid.

It is interesting to hear that this happens for more than just the pro10 - thanks very much for mentioning it. It does sound like these bebob-based saffire devices do shut themselves down (from the point of view of the audio streaming) if data ceases for a certain period of time. Rather than being limited to a single device though, it appears that all similar devices (ie: bebob-based Saffires) may be affected.

If this is related to 'freewheeling mode' as you say, then I think it's a problem with Ardour, not ffado or jack. If Ardour wants to go 'off clock' and process its data files faster (or slower), then it should be on it to disconnect or ignore the streams.

The tricky bit here is that ardour doesn't necessary care about what the device is doing streaming-wise when it drops jackd into freewheeling mode. At the end of the day the device itself should cope with what is being done under the hood, but for some reason it takes the view that it should take itself offline with respect to the firewire bus. As per earlier comments, fixing this could be fiddly.

Jack is a sound server, and once running, should keep going to serve all of its connected applications. Why should a single application have the authority to put the server in a mode that would pull the rug out from under all other connected applications???

This is probably more a question for the jackd developers. Even so, I do consider the behaviour of the the pro10 (and now the pro26) to be wrong. If the computer stops sending audio data for whatever reason, they should not shut their firewire engine off so completely that a major reset is required in order to talk to it again.