From: FFADO <ffa...@ff...> - 2012-04-12 06:41:20
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by stefanr): {{{ handleFcpResponse: FCP response node id's don't match! (ffc1, ffc0) }}} I have not yet looked at the new ffado-jack.log. But this particular error is exactly what libraw1394 would give if it is too old (less than 2.0.6) or compiled against too old kernel headers (less than 2.6.36). About ffado-diag from 04/07/12: {{{ Prerequisites (dynamic at run-time)... libraw1394 ........ 2.0.8 Prerequisites (static at compile-time)... libraw1394 ........ 2.0.5 }}} I always fail to remember what these two different Prerequisites sections want to tell us. Please check with {{{ ldd $(which jackd | sed -e s/bin.jackd//)lib/jack/jack_firewire.so ldd $(ldd $(which jackd | sed -e s/bin.jackd//)lib/jack/jack_firewire.so | grep libffado.so | cut -f3 -d' ') }}} whether jack_firewire or libffado is still linked against an old libraw1394. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:25> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 07:14:58
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by jwoithe): Regarding those prerequisites, a quick glance in ffado-diag tells me the following. * The versions reported as "dynamic at runtime" are obtained by querying the relevant package for its version number, usually via a call to "pkg- config --modversion <name>". * The "static at compile-time" versions are dumped from the file static_info.txt, which for most people would end up in /usr/local/share/libffado/python/. The file itself is generated using the ffado-diag-static script at compile/install time; the versions it reports are those returned from "pkg-config" as run on the system at the time "scons install" was run. Given this, the ffado-diag output from 7 April 2012 indicates that the static_info.txt file being accessed by ffado-diag on 7 April claims that libraw1394 version 2.0.5 was installed at the time this file was created. Theoretically this would have been the version present at compile/install time, but perhaps there's been some other glitch which has meant that static_info.txt is stale on this system. If static_info.txt is accurately indicating the version of libraw1394 that ffado was compiled against, is this an issue? I don't think ffado adapts to the libraw1394 version it's compiled or linked against. Therefore the fact ffado may have been compiled against libraw1394 2.0.5 shouldn't be an issue, should it? What matters is what it's run against, and the system clearly has 2.0.8 installed now. Of course, that still leaves open the possibility that libraw1394 was compiled against headers from a pre-2.6.36 kernel. I'm not sure there's a succinct way of testing for that that, is there? -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:26> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 11:47:12
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): {{{ $ ldd $(which jackd | sed -e s/bin.jackd//)lib/jack/jack_firewire.so linux-gate.so.1 => (0xb778e000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7670000) libjackserver.so.0 => /usr/lib/libjackserver.so.0 (0xb75c8000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb75c3000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb75ba000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb75a1000) libffado.so.2 => /usr/lib/libffado.so.2 (0xb72ba000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7294000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7275000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb712f000) /lib/ld-linux.so.2 (0xb778f000) libiec61883.so.0 => /usr/lib/libiec61883.so.0 (0xb7123000) libraw1394.so.11 => /usr/lib/libraw1394.so.11 (0xb7116000) libconfig++.so.8 => /usr/lib/libconfig++.so.8 (0xb7101000) libxml++-2.6.so.2 => /usr/lib/libxml++-2.6.so.2 (0xb70dc000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb6fb1000) libglibmm-2.4.so.1 => /usr/lib/libglibmm-2.4.so.1 (0xb6f59000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6f1b000) libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0xb6f15000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6f10000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xb6e46000) libz.so.1 => /usr/lib/libz.so.1 (0xb6e32000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6e2e000) libpcre.so.3 => /lib/libpcre.so.3 (0xb6dfb000) }}} $ ldd $(ldd $(which jackd | sed -e s/bin.jackd//)lib/jack/jack_firewire.so | > grep libffado.so | cut -f3 -d' ') linux-gate.so.1 => (0xb7722000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7408000) libiec61883.so.0 => /usr/lib/libiec61883.so.0 (0xb73fc000) libraw1394.so.11 => /usr/lib/libraw1394.so.11 (0xb73ee000) libconfig++.so.8 => /usr/lib/libconfig++.so.8 (0xb73d9000) libxml++-2.6.so.2 => /usr/lib/libxml++-2.6.so.2 (0xb73b4000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb728a000) libglibmm-2.4.so.1 => /usr/lib/libglibmm-2.4.so.1 (0xb7232000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb71f3000) libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0xb71ed000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb71e8000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb71df000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xb7116000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7020000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6ffa000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6fdc000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6e96000) /lib/ld-linux.so.2 (0xb7723000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6e92000) libz.so.1 => /usr/lib/libz.so.1 (0xb6e7d000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6e79000) libpcre.so.3 => /lib/libpcre.so.3 (0xb6e46000) {{{ }}} -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:27> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 11:49:22
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): {{{ $ ldd $(ldd $(which jackd | sed -e s/bin.jackd//)lib/jack/jack_firewire.so | grep libffado.so | cut -f3 -d' ') linux-gate.so.1 => (0xb7722000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7408000) libiec61883.so.0 => /usr/lib/libiec61883.so.0 (0xb73fc000) libraw1394.so.11 => /usr/lib/libraw1394.so.11 (0xb73ee000) libconfig++.so.8 => /usr/lib/libconfig++.so.8 (0xb73d9000) libxml++-2.6.so.2 => /usr/lib/libxml++-2.6.so.2 (0xb73b4000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb728a000) libglibmm-2.4.so.1 => /usr/lib/libglibmm-2.4.so.1 (0xb7232000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb71f3000) libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0xb71ed000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb71e8000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb71df000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xb7116000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7020000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6ffa000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6fdc000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6e96000) /lib/ld-linux.so.2 (0xb7723000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6e92000) libz.so.1 => /usr/lib/libz.so.1 (0xb6e7d000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6e79000) libpcre.so.3 => /lib/libpcre.so.3 (0xb6e46000) }}} -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:28> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 12:55:15
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by stefanr): Replying to [comment:28 j.silvestre]: > libraw1394.so.11 => /usr/lib/libraw1394.so.11 (0xb73ee000) And the date of this file confirms that this is the one which you installed yourself, right? Replying to [comment:26 jwoithe]: > If static_info.txt is accurately indicating the version of libraw1394 that ffado was compiled against, is this an issue? I don't think ffado adapts to the libraw1394 version it's compiled or linked against. Therefore the fact ffado may have been compiled against libraw1394 2.0.5 shouldn't be an issue, should it? What matters is what it's run against, and the system clearly has 2.0.8 installed now. Correct; if a client which was built against libraw1394 2.0.x and libraw1394 is dynamically linked, then it is sufficient to replace the .so.* from 2.0.x to 2.0.y in order to make full use of all 2.0.x->2.0.y fixes. > Of course, that still leaves open the possibility that libraw1394 was compiled against headers from a pre-2.6.36 kernel. I'm not sure there's a succinct way of testing for that that, is there? If one desparately wanted to go to the bottom of it, I guess "strace" could be used to watch whether FW_CDEV_EVENT_REQUEST = 0x2 or FW_CDEV_EVENT_REQUEST2 = 0x6 are read from /dev/fw*, third u_int32_t in the binary read() stream. Or whether the very first ioctl() contains fw_cdev_get_info.version >= 4 as input from client to kernel. --- Perhaps we should simply ship a copy of the kernel header file in the libraw1394 sources to eliminate this worry. j.silvestre, something like "grep FW_CDEV_EVENT_REQUEST2 /usr/include/linux/firewire-cdev.h" would have found occurrences of this _REQUEST2 at the time when you built libraw1394, right? -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:29> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 13:24:25
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): Yes the date of the file libraw1394.so.11 confirms that it's the one I've installed. "grep FW_CDEV_EVENT_REQUEST2 /usr/include/linux/firewire-cdev.h" says nothing at all. Maybe the problem comes from this:? {{{ 7.1.1 Kernel headers Most "normal" programs don't need kernel headers and in fact may break if you use them directly; instead they should be compiled against the headers with which glibc was built, which are the versions in /usr/include/linux and /usr/include/asm of the Debian system. So do not put symlinks to the directories in /usr/src/linux from /usr/include/linux and /usr/include/asm, as suggested by some outdated documents. If you need particular kernel headers for some kernel-specific application programs, alter the makefile(s) so that their include path points to dir- of-particular-kernel-headers/include/linux and dir-of-particular-kernel- headers/include/asm. }}} -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:30> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 13:56:09
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): So I copy firewire include files from linux-headers 3.0.27-rt46 in /usr/include/linux and then rebuild libraw1394. Now FFADO uses both devices together. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:31> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 14:01:19
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by wagi): So adding something like {{{ grep FW_CDEV_EVENT_REQUEST2 /usr/include/linux/firewire-cdev.h" }}} to ffado-diag would be a good idea, no? :) -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:32> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 14:11:47
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by jwoithe): Replying to [comment:31 j.silvestre]: > So I copy firewire include files from linux-headers 3.0.27-rt46 in /usr/include/linux and then rebuild libraw1394. Now FFADO uses both devices together. Great stuff. So the cause of the inability to aggregate these two devices was the fact that the new libraw1394 was compiled against old kernel headers. It's good to get to the bottom of that. Thanks Stefan for leading us towards the solution. So, having resolved that little side issue, the remaining question is whether the subject of this ticket is still an issue with the newer libraw1394/kernel/ffado. Obviously given the intermittent nature of the fault a reasonable amount of testing may be needed. However, any feedback you can give as to the probable state of those xruns with the newer software would be appreciated. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:33> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 14:16:44
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by jwoithe): Replying to [comment:32 wagi]: > So adding something like > [[BR]] > grep FW_CDEV_EVENT_REQUEST2 /usr/include/linux/firewire-cdev.h" > [[BR]] > to ffado-diag would be a good idea, no? :) Perhaps. However, the critical point isn't what that header says at the time that ffado is compiled, but rather what header was present when libraw1394 was compiled. In other words, what we really want to know is whether a suitably new kernel header was present when libraw1394 was compiled. Since libraw1394 may come from a binary distribution there's no guarantee that the kernel headers on a user's computer match those used on the machine to compile the binary. So while adding this to ffado-diag may be useful to a point, one would have to be very careful when basing any conclusions on the subsequent reports. For these reasons I'm more of the view that it's better left out, but I'm open to contrary arguments. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:34> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 15:38:04
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by stefanr): Replying to [comment:30 j.silvestre]: Admittedly I know close to nothing how distributors deal with kernel header files. I only know how it is done on Gentoo: There, a package named linux-headers provides header files which are already appropriately converted from the original kernel source headers. Independently of Linux distributions, it is generally true that the header files from a kernel source tarball or kernel source package should not be used directly to build userland programs against them or copy them to /usr/include. In case of the two "linux/firewire-c*.h" files, those can be copied without worry because they don't require conversion. Also, libraw1394's ./configure contains an option with which it is possible to specify a custom directory with "linux/firewire-c*.h" in them. --- Anyway; this incident convinced me to copy these two header files directly into the libraw1394 sources in order to avoid all this from the next libraw1394 release on. Sorry for all the confusion. Replying to [comment:34 jwoithe]: I agree that this kind of test in ffado-diag would not be reliable at all. Let me think about whether there is a way to do a proper runtime test for libraw1394 features. Back to the subject of this ticket: Two devices aggregated will certainly stress the FFADO stream engine, the kernel, and the controller more than a single audio device. j.silvestre, the new kernel which you are now using hopefully behaves better than the one from when you opened this ticket. When you get around to test this some more, remember that very large buffers may in fact degrade FFADO's ability to keep the streams stable. This also somewhat depends on the particular IEEE1394 controller, as far as I have heard. IOW medium-sized buffers are typically easiest to handle for FFADO on many systems. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:35> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-12 15:53:18
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): So what buffer size do you recommend for a meaningfull test? Jackd is now running with both devices and already generate an Xrun after about 30mn with 3 buffers of 1024 samples. Unfortunately I've lost the log file by mistake. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:36> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-13 00:18:11
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by jwoithe): In relation to buffer sizes, there's a trade-off: the larger the buffer size the lower the rate of interrupts and therefore potentially there's CPU load savings to be had. On the other hand, if the buffers are too large it can be difficult to keep the device synced because of the way the various protocols function (with some devices being more prone to problems than others). I've seen numbers of 256, 512 and 1024 being mentioned in the context of "medium-sized". You reported that with a buffer size of 1024 you managed to get an xrun. In a way that's good because it obviously didn't take too long to trigger; I suspect it should be fairly easy for this test to be replicated to recreate the accidently lost log file. This is probably valuable since it may give us an indication as to what went wrong (that is, whether there is a problem lurking within FFADO, or if it's due to some as-yet-unidentified local issue). As far as testing for stability, it would then be interesting to try with buffer sizes of 512 and/or 256 and see if that improves things in any way. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:37> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-13 10:44:20
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): Finally got and log an Xrun. Don't know if it's important or not, the two devices are bus synchronised. If needed I can sync them with spdif. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:38> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-13 13:31:15
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): An other one. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:39> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-14 23:52:06
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by jwoithe): In general when running multiple digital audio devices - no matter what the setting - it is important to ensure they are all synchronised to the same digital clock. I'm not sure whether FFADO's streaming system is designed to cope with devices which are running from different digital clocks, but I would suggest it would be a good idea to run the devices synchronous in any case. In light of this I think it would be good to arrange for the devices to be synchronised to the same clock and then test that with FFADO. Syncing them via SPDIF as you proposed would be fine. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:40> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-21 16:34:29
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): Syncing devices via spdif doesn't change xruns occurence. Smaller buffers neither, 256 samples instead of 1024 and xruns are still here. I have the log files but they are quite big, up to 100Mo after commpression. Now Jackd is running with the saffire alone. Waiting for xrun... -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:41> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-22 04:32:17
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by jwoithe): Thanks for testing with the devices synched via SPDIF. It was a bit of a long shot that this would fix the problem, but it's still good to have confirmed that the xruns have nothing to do with that. Similarly for the use of smaller samples - it's good to have ruled that out too. For the moment just hold onto the log files locally - don't try to put them up somewhere, given their size. They probably don't give any more information than the logs already posted. Testing with each device separately for an extended period of time is a good idea. If the frequency of xruns is lower than with both devices active we can conclude that there's something about the aggregated device setup that's causing this. Whether it's a fundamental bug, or something that occurs due to the increased CPU workload, remains to be seen. Let's wait and see the outcome of this latest round of tests. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:42> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-01 18:49:29
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): Ten days of continous streaming with the saffire at 3x256 samples and still no xrun. Should I do the same test with the FA101? -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:43> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-02 00:48:37
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by jwoithe): Wow. That's some test. I think we can reasonably conclude that the Saffire is stable on your system in isolation. :-) I think it would be worth doing the same thing with the FA101. You probably don't have to run all the way to 10 days if you don't want to - I'll leave the final time length up to you. Assuming that this also proves stable it will pretty much confirm that the problem is triggered through the use of both devices simultaneously. We can then concentrate on that. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:44> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-06 10:17:31
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by j.silvestre): Finally got an unhandled xrun with a single device. Took quite a long a time, about 4 days. As the log file is a bit heavy I cut it to keep only the begining and the end. This file is ffado-jack-fa101-256-strip.log. If needed, full log is available at http://jdlv.homelinux.org/ffado-jack- fa101-256.log.xz -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:45> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-06 12:10:49
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by jwoithe): Regarding [comment:45 comment 45], it's very interesting that it took 4 days before an unhandled xrun was generated, especially since the other device kept going for 10 days without a hint of a problem. It does suggest that perhaps there might be an issue in the FA101 driver which is upsetting the Saffire/FA101 aggregation. Perhaps the aggregation makes the underlying problem - whatever that may be - somewhat more likely. Of course it's also possible that this was a transient error condition which has never happened before and is totally unrelated to the problems you see when the two devices are aggregated. The pertinent lines from the log appear to be the following. {{{ Debug (IsoHandlerManager.cpp)[ 417] waitForActivity: (0x94bf708) sem_timedwait() timed out (result=-1) Warning (IsoHandlerManager.cpp)[ 292] Execute: Timeout while waiting for activity Fatal (IsoHandlerManager.cpp)[ 348] Execute: (0x94bf838, Receive) Handler died: now: CE2FB0FC, last: C7A37897, diff: 80029797 (max: 49152000) Warning (StreamProcessor.cpp)[ 173] handlerDied: Handler died for 0x94ef308 Debug (PosixThread.cpp)[ 94] ThreadHandler: (ISORCV) ThreadHandler: exit 0x94bf958 Debug (StreamProcessorManager.cpp)[1340] waitForPeriod: exit due to xrun... Debug (StreamProcessorManager.cpp)[1397] waitForPeriod: Xrun on RECV SP 0x94ef308 due to ISO side xrun }}} As far as I can remember, this is basically saying that the incoming data (from the audio device) stopped for no reason. That is, from the point of view of FFADO, the device stopped sending audio data. This is what is meant by "ISO side xrun": the receive threads had a buffer under-run caused by a lack of data coming in from the firewire iso stream. The xrun noted in ffado-jack-both-xrun-1024-1.log.xz seems to be slightly different from what we see above: waitForActivity() does not report a problem, nor do we see any notification of "Handler died". Instead, among other things we see things like {{{ putPacket: (0x8bf6070) dropped 17 packets on cycle 3090, 'dropped'=0, cycle=3090, m_last_cycle=3072 }}} I think this is a notification by the FFADO receiver that we failed to see any data from the device for (in this case) 18 iso cycles. This is not totally unrelated to what we infer from the latest log file; the difference is that in ffado-jack-both-xrun-1024-1.log.xz the device starts sending data again before FFADO gives up on it, while in the latest log FFADO decides that the data flow has ceased and reacts accordingly. The common theme here is that data from the device is being interrupted for an extended period of time. In both cases there's no obvious sign as to why this might have occurred. Interestingly enough, I note that it is the receive processor of the FA101 which gives trouble in ffado-jack-both-xrun-1024-1.log.xz and in the most recent test. So maybe there's something about the FA101 which is causing it to cease sending data for a certain length of time, and that the action of running two devices on the bus somehow makes the problem more likely to occur. In any case, we're still left wondering why we are apparently seeing an interruption in the data stream from the device. It could be a strange FFADO bug, a physical problem with the device (either a bug or a fault), an issue with the PCIxx12 firewire card, or something else I'm overlooking. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:46> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-06 18:14:53
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by wagi): > In any case, we're still left wondering why we are apparently seeing an interruption in the data stream from the device. It could be a strange FFADO bug, a physical problem with the device (either a bug or a fault), an issue with the PCIxx12 firewire card, or something else I'm overlooking. I would not rule out that the FA-101 is just buggy. The FA-101 was the first product with the DM1000 chip and it has an early version of the BeBoB stack. Both have more than enough known bugs which are normally hidden. But running the device for 4 days might just trigger one of those. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:47> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-06 23:23:11
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by jwoithe): Replying to [comment:47 wagi]: > The FA-101 was the first product with the DM1000 chip and it has an early version of the BeBoB stack. Both have more than enough known bugs which are normally hidden. But running the device for 4 days might just trigger one of those. Would it therefore be a stretch to consider that running the FA101 aggregated with another device might then make the problem easier to trigger? Otherwise, if we are to put this down to a buggy device we still have to explain why running the FA101 with another device seems to take FFADO down much sooner. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:48> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-16 06:06:16
|
#216: Unhandled XRUN ---------------------------+------------------------------------------------ Reporter: j.silvestre | Owner: Type: bug | Status: reopened Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO SVN (2.0 branch) Resolution: | Keywords: Device_name: | ---------------------------+------------------------------------------------ Comment (by wagi): Replying to [comment:48 jwoithe]: > Replying to [comment:47 wagi]: > > The FA-101 was the first product with the DM1000 chip and it has an early version of the BeBoB stack. Both have more than enough known bugs which are normally hidden. But running the device for 4 days might just trigger one of those. > > Would it therefore be a stretch to consider that running the FA101 aggregated with another device might then make the problem easier to trigger? Yes, that is what I assume. The saffire did run without troubles with the same setup for a long time and the FA-101 not. Maybe it is just coincidence. If you want to rule this out a bigger sample pool is needed... > Otherwise, if we are to put this down to a buggy device we still have to explain why running the FA101 with another device seems to take FFADO down much sooner. Either we answer this question or we ask the reported to do more tests but I don't think we should. I have a FA-101 still here (not used for long time, don't know if it still works) with a serial console to it. There are some limited way to debug the device but it is really long time ago and I did not really work with that unit. So I could give it a spin. But I wouldn't expect any answers. -- Ticket URL: <http://subversion.ffado.org/ticket/216#comment:49> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |