From: FFADO <ffa...@ff...> - 2012-07-20 10:24:43
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode ---------------------+------------------------------------------------------ Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: Component: generic | Version: FFADO SVN (trunk) Keywords: | Device_name: focusrite saffire pro 10 i/o ---------------------+------------------------------------------------------ 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). -- Ticket URL: <http://subversion.ffado.org/ticket/359> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-20 12:21:04
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: Component: generic | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by adi): Which ffado version is this? And more importantly, which exact jackd version do you use? -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:1> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-20 12:27:39
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: Component: generic | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:2> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-20 12:28:57
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/dice | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by jwoithe): Replying to [comment:1 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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:4> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-20 13:00:34
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/dice | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:5> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-20 13:10:02
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by jwoithe): Replying to [comment:5 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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:7> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-22 14:25:53
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by stefanr): Replying to [comment:7 jwoithe]: > Replying to [comment:5 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 -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:8> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-22 14:47:15
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by stefanr): Replying to [ticket:359 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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:9> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-22 15:12:42
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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". -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:10> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-22 23:37:16
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by jwoithe): Replying to [comment:10 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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:11> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-23 09:34:25
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:12> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-24 11:40:35
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by jwoithe): Mikkl: thanks for your clarification in [comment:12 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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:13> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-30 08:59:28
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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? -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:14> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-30 23:35:51
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by jwoithe): Mikkl: regarding [comment:14 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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:15> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-31 07:12:07
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by stefanr): Replying to [comment:15 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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:16> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-31 12:12:28
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:17> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-07-31 19:10:05
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by mikkl): Replying to [comment:17 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! -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:18> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-08-02 09:52:13
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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 }}} -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:19> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-08-02 13:23:33
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by stefanr): Replying to [comment:19 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.) -- Ticket URL: <http://subversion.ffado.org/index.fcgi/ticket/359#comment:20> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-08-06 15:32:53
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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. -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:21> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-08-06 23:27:03
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (by jwoithe): Mikkl: no problem. Enjoy your time away and we'll catch up when you get back. Referring back to [comment:19 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. -- Ticket URL: <http://subversion.ffado.org/index.fcgi/ticket/359#comment:22> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-08-14 15:54:01
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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! -- Ticket URL: <http://subversion.ffado.org/index.fcgi/ticket/359#comment:23> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-08-24 11:29:00
|
#359: focusrite saffire pro 10 i/o device fails to come back online after jack goes into freewheel mode --------------------------------------------+------------------------------- Reporter: mikkl | Owner: Type: bug | Status: new Priority: major | Milestone: FFADO 2.2 Component: devices/bebob | Version: FFADO SVN (trunk) Resolution: | Keywords: Device_name: focusrite saffire pro 10 i/o | --------------------------------------------+------------------------------- Comment (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? -- Ticket URL: <http://subversion.ffado.org/ticket/359#comment:24> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: Adrian K. <ad...@dr...> - 2012-08-24 13:40:45
|
On Fri, Aug 24, 2012 at 11:28:49AM -0000, FFADO wrote: > 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? Something like this: ffado_enter_freewheel(); --> a new or sleeping ffado thread sends zeroes and discards data from the device ffado_leave_freewheel(); --> back to normal operation This should be fairly simple to mimic from jackd. If you could make FFADO keep the streams running without being called from jackd (let's call it "in detached mode"), I'd volunteer to provide the necessary additions for jackd1 and jackd2. WDYT? -- mail: ad...@th... http://adi.thur.de PGP/GPG: key via keyserver |
From: Jonathan W. <jw...@ju...> - 2012-08-25 11:22:40
|
Hi Adrian > > 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? > > Something like this: > > ffado_enter_freewheel(); > --> a new or sleeping ffado thread sends zeroes and discards data > from the device > > ffado_leave_freewheel(); > --> back to normal operation I guess that could work. The "new or sleeping" ffado thread would need to run at high priority and be capable of being woken very quickly, but I guess that could be arranged with semaphores and/or a conditional waits on a mutex. Or something. > This should be fairly simple to mimic from jackd. If you could make > FFADO keep the streams running without being called from jackd (let's > call it "in detached mode"), I'd volunteer to provide the necessary > additions for jackd1 and jackd2. I think that any addition like this is clearly a post-2.1 thing. I'm open to looking into something along these lines although I'm conscious of the fact that this would consitute an elaborate workaround used by all devices but needed by only one. For this reason, before proceeding it would be good to get confirmation that all 10 i/o devices behave like this and that ticket #359 isn't referring to behaviour that's due to the particular hardware in use by the reporter. Thanks for being willing to see a solution through for jackd1 and jackd2. Regards jonathan |