From: FFADO <ffa...@ff...> - 2014-07-21 13:11:14
|
#380: Segmentation fault with JACK in version 2.2.1 ----------------------------+----------------------------------------------- Reporter: dave.ze.rave | Owner: jwoithe Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: devices/rme | Version: FFADO SVN (trunk) Resolution: | Keywords: fireface800 Device_name: | ----------------------------+----------------------------------------------- Changes (by jwoithe): * priority: blocker => major Comment: Thanks for posting the additional information and the debug log. The log in particular appears to show the cause of the trouble. First up we have this: {{{ get_hardware_state: State reported by hardware: : get_hardware_state: clock_mode: autosync/slave }}} This suggests that the device is set up with the sync source set to "autosync/slave". In other words, the FF800 is configured to look for an external clock. A little while later we see: {{{ setSamplingFrequency: slave clock mode active but no valid external clock present initStreaming: Could not set sampling frequency to 48000 ffado_streaming_init: Could not init the streaming system }}} While the FF800 is set to search for an external clock, it appears to be reporting that there is no valid external clock available (this is consistent with the rest of the get_hardware_state output, which also indicates the lack of any external clock signals). As a result the FF800 cannot verify the requested sample rate (48k) and therefore errors out. I will freely admit that the errors reported via jackd without FFADO's "-v6" option active could be slightly more informative, but fixing this is a relatively involved task for various reasons. That aside, the lack of a valid external clock signal is the apparent cause of your startup error. The first thing to check would be to use ffado-mixer to see what the clock source is set to. Note that for the RME devices this is configured in the body of the "Control" tab rather than the generic dropdown control because the RME interfaces deal with clock sources in a different way to most other devices. Change the clock source to "master", optionally exit ffado-mixer, and try starting jackd again. See what happens and let me know the results. As to why earlier FFADO versions work, I think this is due to the fact that FFADO 2.2.x now attempts to obtain as much of its initial operating configuration from the Fireface itself (or more accurately, from the configuration stored in the Fireface's flash). In contrast, FFADO 2.1.x forced its own preconfigured setup onto the device at startup which included the use of the internal clock. Therefore, if your Fireface's configuration stored in flash happens to be set up to select autosync/slave mode as the clock source, it is entirely possible that FFADO 2.1.x will behave differently to 2.2.x. Finally, the segmentation fault you saw in your initial tests appears to originate in jackd code. As far as I can tell FFADO is returning an error code back to jackd; it seems that jackd is not quite handling this right and the jackd code segfaults. Interestingly enough, as far as I can tell your manual running of jackd did not segfault so the problem might be due to an interaction between jack2 and qjackctl when a backend's startup returns an error. -- Ticket URL: <http://subversion.ffado.org/ticket/380#comment:3> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |