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 |