From: FFADO <ffa...@ff...> - 2009-11-28 11:13:45
|
#242: ntp interferes with ffado ----------------------------------------+----------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.0 Version: FFADO 2.0-rc2 (1.999.42) | Keywords: Device_name: all | ----------------------------------------+----------------------------------- As I was taught recently, sometimes it is necessary to configure _small_ buffers to avoid xruns. Furthermore I learned just yesterday that jackd/ffado crashed (i.e. exited unexpectedly) on my current working PC due to interference by ntpd (the network time daemon). Lines in /var/log/messages like Nov 25 23:19:17 stein ntpd[7685]: time reset +2.020631 s Nov 25 23:35:18 stein ntpd[7685]: time reset +1.945118 s Nov 25 23:50:44 stein ntpd[7685]: time reset +2.053456 s coincided with when ffado exited. This was always accompanied by firewire ERR: wait status < 0! (= -1) DRIVER NT: could not run driver cycle in jackd's log. I have since disabled the ntpd system service and these crashes are gone. Furthermore, fast successions of xruns seemed to possibly cause jackd/ffado crashes too So if you are able to get rid of the xruns e.g. by means of a smaller buffer, you might cure your crashes as a very welcome side effect. [Disclaimer: I'm a FFADO newbie and don't know what I'm talking about.] -- Stefan Richter -- Ticket URL: <http://subversion.ffado.org/ticket/242> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2010-05-23 13:52:01
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): The description lumps several unrelated issues together. Clarification: The subject issue here --- ''reset of the local clock by ntpd causes ffado/ jackd to die'' --- is 100% reproducible on my system and independent of which controller and which kernel drivers are in use. As a means for a possible fix, a [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=abfe5a01ef1e463cbafdae461b693db34e308c02 new ioctl] has been added to firewire-core in kernel 2.6.34 which lets userspace choose between CLOCK_REALTIME, CLOCK_MONOTONIC, and CLOCK_MONOTONIC_RAW as the local clock, similar to clock_gettime() of libc. I am not exactly sure whether POSIX' CLOCK_MONOTONIC or Linux' CLOCK_MONOTONIC_RAW is the right one to fix this bug. The firewire-core and raw1394 ioctls which back libraw1394's raw1394_read_cycle_timer() use CLOCK_REALTIME and are thus exposed to clock jumps due to ntpd and the likes. There hasn't been a move to extend libraw1394 to the new ioctl yet. Ways to do that could be - a new libraw1394 function as alternative to raw1394_read_cycle_timer(), - a libraw1394 environment variable that alters the behavior of raw1394_read_cycle_timer(). Either way would require changes to both libffado and libraw1394. The latter way may not be such a good idea, it seems more convoluted. If somebody implements a ffado backend to the new kernel driver stack that bypasses libraw1394 entirely, then the new ioctl should be used instead of FW_CDEV_IOC_GET_CYCLE_TIMER. (IMO, kernel 2.6.34 could be made a hard requirement of such a backend, considering that there are other important advantages in that one over .32 or .33.) -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:1> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2010-05-24 15:39:00
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): Affected: jackd + ffado + linux1394 jackd + ffado + juju Not affected: jackd + alsa -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:2> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-27 14:30:31
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): Wouldn't this affect jackd's timing as much as FFADOs? In other words, even if FFADO were to utilise an alternative clock source, wouldn't jackd remain exposed? Or does jackd take care to choose the best clock available? Is this a large enough issue to maintain it as a 2.1 milestone? Given that there's no move on the horizon to rewrite ffado to use the new stack directly, the fix seems fairly involved as it would span FFADO and libraw1394 at the very least. Is there anyone with the time and required knowledge who could oversee such a fix within the next month? If not, I propose postponing this to at least FFADO 2.2. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:3> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-27 21:22:30
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.1 Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): Replying to [comment:3 jwoithe]: > Wouldn't this affect jackd's timing as much as FFADOs? In other words, even if FFADO were to utilise an alternative clock source, wouldn't jackd remain exposed? Or does jackd take care to choose the best clock available? I can't answer that. All I know is that jackd remains undisturbed by local clock resets if it uses an ALSA device instead of FFADO. > Is this a large enough issue to maintain it as a 2.1 milestone? Given that there's no move on the horizon to rewrite ffado to use the new stack directly, the fix seems fairly involved as it would span FFADO and libraw1394 at the very least. Adding a new function to libraw1394 and getting it released would be one of the easier aspects of this problem. Could take some time to trickle out into distributions of course. > Is there anyone with the time and required knowledge who could oversee such a fix within the next month? If not, I propose postponing this to at least FFADO 2.2. As reporter, I definitely don't mind if you postpone this; a 2.1 release should not be blocked by this. Of course it is hard to say how mayn people are affected by this. At the time when I discovered the problem, I had an ntpd installation which logged every clock reset to the syslog. After an ntpd update quite a while ago, it doesn't do so anymore (on Gentoo Linux, and certainly on other distros), so now I would be totally clueless why jackd + ffado always dies with unhandled xrun after 0...15 minutes runtime. So WRT ability to detect the presence of this issue on any other affected user's setup, this is quite a nasty problem. On the flipside, as soon as Clemens and you are done implementing kernelspace streaming components, this issue is resolved as well. :-) -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:4> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-27 23:29:01
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Changes (by jwoithe): * milestone: FFADO 2.1 => FFADO 2.x Comment: Replying to [comment:4 stefanr]: > Replying to [comment:3 jwoithe]: > > Is this a large enough issue to maintain it as a 2.1 milestone? Given that there's no move on the horizon to rewrite ffado to use the new stack directly, the fix seems fairly involved as it would span FFADO and libraw1394 at the very least. > > Adding a new function to libraw1394 and getting it released would be one of the easier aspects of this problem. Could take some time to trickle out into distributions of course. As I understand it, there are two aspects to this approach: * get the new function in libraw1394 * make ffado use the new function if it's available (we'd need scons to check for this so as to not require that everyone upgrade libraw1394 if they have no need to do so) To me there seems little reason not to request that the new function go into libraw1394 as soon as possible. Once it's there we can have FFADO call it. This would, from my understanding of the problem, resolve the issue as much as we can. What is the policy of adding new functions to libraw1394? Is any attempt made to maintain backwards compatibility through the use of weak linkage? I guess another option which avoids the need for people to upgrade libraw1394 immediately would be to add the function to FFADO's code base; if a sufficiently new version of libraw1394 were available then the libraw1394 function could be called; otherwise we could just go ahead and do the ioctl() ourselves. In time, once the new libraw1394 has propagated into distributions we could remove the FFADO version. Does this sound like a reasonable plan? > As reporter, I definitely don't mind if you postpone this; a 2.1 release should not be blocked by this. Ok, thanks. However, if it does boil down to the changes noted above, and if the above process is acceptable we could probably come up with something fairly quickly. I've changed the milestone to 2.x, but if it happens to make 2.1 then great. > Of course it is hard to say how mayn people are affected by this. True. I've never run ntpd on my audio machines so it's not something which has ever affected me. It probably comes down to how many distributions enable ntp out the box (or via a simple click-through interface during installation). > So WRT ability to detect the presence of this issue on any other affected user's setup, this is quite a nasty problem. Agreed. The time jumps instigated by ntpd are of variable length, so there's no point in FFADO attempting to deduce whether the time jump is due to NTP or something else. FFADO could print a warning if such a jump is seen saying the NTP sometimes causes this, but since most people run jack via qjackctl they probably won't see it. So coming up with something which might fix the problem in some cases is probably better than doing nothing. We could possibly add a check for a running ntpd to ffado-diag. I might look into doing this tonight. > On the flipside, as soon as Clemens and you are done implementing kernelspace streaming components, this issue is resolved as well. :-) True, but that is still a way off (I need to see an example playback implementation before I know enough to port other drivers to the in-kernel option). Therefore, if there is a way of working around the NTP issue in a relatively clean way we should probably aim to do so. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:5> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-28 21:32:10
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): Replying to [comment:5 jwoithe]: > What is the policy of adding new functions to libraw1394? Is any attempt made to maintain backwards compatibility through the use of weak linkage? Although my being libraw1394 maintainer, I am new to this and not sure. But my understanding is that there would be a new function added to libraw1394, libraw1394's minor version number be incremented, and that would be it. > I guess another option which avoids the need for people to upgrade libraw1394 immediately would be to add the function to FFADO's code base; if a sufficiently new version of libraw1394 were available then the libraw1394 function could be called; otherwise we could just go ahead and do the ioctl() ourselves. In time, once the new libraw1394 has propagated into distributions we could remove the FFADO version. The libraw1394 API does not expose a file descriptor that could be used for such a purpose. > > Of course it is hard to say how mayn people are affected by this. > > True. I've never run ntpd on my audio machines so it's not something which has ever affected me. It probably comes down to how many distributions enable ntp out the box (or via a simple click-through interface during installation). It is not the mere act of running ntpd that throws FFADO off. It becomes an issue only if the RTC is exceedingly bad (like the one on my main PC which is >2000 ppm too slow, causing ntpd to reset the clock by +2 seconds every 15 minutes, instead of its usual harmless gradual adjustments). However, of course also any other clock adjustment, e.g. manually by the user, kills FFADO. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:6> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-28 22:59:36
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): Replying to [comment:6 stefanr]: > Replying to [comment:5 jwoithe]: > > What is the policy of adding new functions to libraw1394? Is any attempt made to maintain backwards compatibility through the use of weak linkage? > > ... But my understanding is that there would be a new function added to libraw1394, libraw1394's minor version number be incremented, and that would be it. Hmm, ok, so if this were to be utilised without breaking things for people who didn't need the added burden of upgrading libraw1394 just to try FFADO trunk, FFADO would have to check libraw1394 for the existance of the new function at compile time and conditionally use it if it was found. One can do this with autoconf so I guess scons can too (I've just got to look up the documentation). This wouldn't make the feature runtime detectable (for that you need weak linkage) but in the scheme of things I doubt that is going to be a practical issue. In cases like this where few people really require the new libraw1394 feature, I'm more concerned about making it possible for users to keep trying FFADO trunk without having to mess with other libraries on the system. > > I guess another option which avoids the need for people to upgrade libraw1394 immediately would be to add the function to FFADO's code base ... > > The libraw1394 API does not expose a file descriptor that could be used for such a purpose. Ah, ok. Well, that kills off that alternative then. > It is not the mere act of running ntpd that throws FFADO off. It becomes an issue only if the RTC is exceedingly bad (like the one on my main PC which is >2000 ppm too slow, causing ntpd to reset the clock by +2 seconds every 15 minutes, instead of its usual harmless gradual adjustments). However, of course also any other clock adjustment, e.g. manually by the user, kills FFADO. Thanks for the qualification. On balance I think the best way to resolve this issue is the following: * get the new function into libraw1394 as soon as is practical. * code FFADO to use the new function in the event that it is present at compile time. I should be able to deal with the FFADO side of things. Can you take care of libraw1394? -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:7> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-30 07:13:53
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): Replying to [comment:7 jwoithe]: > Hmm, ok, so if this were to be utilised without breaking things for people who didn't need the added burden of upgrading libraw1394 just to try FFADO trunk, FFADO would have to check libraw1394 for the existance of the new function at compile time and conditionally use it if it was found. One can do this with autoconf so I guess scons can too (I've just got to look up the documentation). This would be desirable, even though libraw1394 upgrades are not overly hard. (...) > Can you take care of libraw1394? OK, I will do as soon as spare time permits. Keep an eye on linux1394- devel. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:8> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-31 19:03:45
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): Replying to [comment:7 jwoithe]: > FFADO would have to check libraw1394 for the existance of the new function at compile time and conditionally use it if it was found. http://scons.org/doc/HTML/scons-user/x4167.html looks like the configuration test is as easy as {{{ if conf.CheckFunc('raw1394_read_cycle_timer2') conf.env.Append(CPPDEFINES = '-DHAVE_RAW1394_READ_CYCLE_TIMER2') }}} Or the libraw1394 version number could be tested. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:9> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-04-01 12:51:56
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): In relation to comment [comment:9]: yes, it looks to be that easy. Either approach mentioned would work - it would depend on one's mood at the time as to which one was chosen. The generally accepted approach in situations like this is (I think) to test for a feature rather than a version number so I'd probably go for that (of course version number checks are useful when there's been a critical bugfix in existing functions). -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:10> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-11 12:01:53
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): Replying to [comment:8 stefanr]: > > Can you take care of libraw1394? > > OK, I will do as soon as spare time permits. Keep an eye on linux1394- devel. I gather time has not yet permitted (either that or I've missed a bunch of linux1394-devel digests). Realistically, when do you think you'll have a chance to look into this new libraw1394 function? Is it something we can expect in the next month or so (in which case we can have ffado use it for the 2.1 release), or will it slip into Q3 2012? -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:11> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-11 18:13:18
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): I have not done this yet; I will Cc you when I get to it. I am thinking of a new function which is extended relative to raw1394_read_cycle_timer() similar to how FW_CDEV_IOC_GET_CYCLE_TIMER2 is extended relative to FW_CDEV_IOC_GET_CYCLE_TIMER: http://lxr.linux.no/#linux+v3.3/include/linux/firewire-cdev.h#L853 As the first and maybe even only user of this extended API, do you prefer to keep the local_time out-parameter as u_int64_t *local_time /* local system time in microseconds since Epoch */ or should we change it to struct timespec *tp /* local system time in seconds and nanoseconds (since the Epoch) */ like the respective out-parameter of clock_gettime()? -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:12> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-05-12 11:59:05
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): To be honest I'm not all that fussed. Obviously if we maintain the system of the call this is modeled after it'll make it truly a drop-in replacement within the FFADO code. However, in the interests of future- proofing the API (for cases where extended resolution may be needed) perhaps we ought to go with the microseconds approach. At the end of the day, running with the timespec parameter isn't going to create any issues from FFADO's end that I can see. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:13> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-19 12:18:15
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): Initial patches which add raw1394_read_cycle_timer_and_clock() to libraw1394 (to be included in libraw1394 2.1.0) have been released. Svn r2167 includes a first cut at code to make use of this function if it is available at run time. The intent here is that if one runs with libraw1394 2.1.0 with r2167 or later, FFADO should be relatively immune to disruptions caused by NTP time adjustments due to the use of the CLOCK_MONOTONIC_RAW clock source. In other words, if the theory developed in this ticket is correct, r2167 with a suitably new libraw1394 should resolve the NTP interference problem. r2167 has been tested and verified not to cause trouble when using libraw1394 earlier than 2.1.0. It is entirely possible that the need for some tweaks will become apparent once testing starts with the revised libraw1394. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:14> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-22 19:16:09
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): Here is what I tested now: * installed the modified libraw1394 * built and installed ffado r2166 * stopped ntpd * started jackd with Saffire PRO24 on a TI XIO2213A/B card * ran it for about 100 minutes without a single xrun * started ntpd, got jackd killed after a few minutes (So all this confirms that I have a well-working system with r2166 if ntpd is off, but still get instant crash of jackd if the realtime clock is reset. Next steps:) * checked out r2167, did scons -c and deleted all the ffado stuff in /usr/local (the scons install routines have frequently been extremely unreliable and unpredictable for me), then built and installed ffado r2167 * started jackd with Saffire PRO24 (needed to switch it off and on again before ffado succeeded to recognize the Saffire as such) * got frequent xruns, connected with a brief audible gap (10 xruns in 25 minutes) and unhandled xruns with crash (2 of those in 25 minutes) * tried "date -s ..." and thus provoked xruns or even unhandled xruns = crash. The startup message says "ffado_streaming_init: libffado 2.999.0-2167 built Jun 22 2012 19:39:10", so there is at least a chance that I am indeed running r2167. Starting jackd with trailing -v6 shows boatloads of lines like {{{ 2279659063900: Warning (cycletimer.h)[ 97] wrapAtMaxTicks: insufficient wrapping: 32885376728681314 2279659063905: Warning (IsoHandlerManager.cpp)[1651] getPacket: reconstructed CTR counter discrepancy 2279659063908: Warning (IsoHandlerManager.cpp)[1657] getPacket: ingredients: 51A, 9851A000, 9651A106, 96790B62, 9678C106, 76, 75, 75, 1847212294 2279659063913: Warning (IsoHandlerManager.cpp)[1658] getPacket: diffcy = -626 }}} continuously scrolling by pretty fast. This is regardless whether ntpd is running or not. * switched off ntpd * reverted to ffado r2166 * started jackd with -v6, got none of those ctr discrepancies * kept jackd running without xruns for another hour So, it seems the new CLOCK_MONOTONIC_RAW usage conflicts with other parts in ffado itself or in the entire application stack that still use CLOCK_MONOTONIC or CLOCK_REALTIME. AFAIU all three clocks run at the same speed if left alone (i.e. if no ntpd or date or friends are being used); they merely have different start offsets. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:15> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-22 21:22:45
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by cladisch): Oh well: {{{ src/bebob/bebob_dl_mgr.cpp: clock_gettime(CLOCK_REALTIME, &timeout); src/debugmodule/debugmodule.cpp: clock_gettime(CLOCK_MONOTONIC, &ts); src/libieee1394/IsoHandlerManager.cpp: if (clock_gettime(CLOCK_REALTIME, &ts) == -1) { src/libieee1394/ieee1394service.cpp: err = raw1394_read_cycle_timer_and_clock(m_util_handle, &cycle_timer, &local_time, CLOCK_MONOTONIC_RAW); src/libieee1394/ieee1394service.cpp: err = raw1394_read_cycle_timer_and_clock(m_util_handle, cycle_timer, local_time, CLOCK_MONOTONIC_RAW); src/libstreaming/StreamProcessorManager.cpp: if (clock_gettime(CLOCK_REALTIME, &ts) == -1) { src/libutil/PosixMessageQueue.cpp: clock_gettime(CLOCK_REALTIME, &timeout); src/libutil/PosixMessageQueue.cpp: clock_gettime(CLOCK_REALTIME, &timeout); src/libutil/PosixMessageQueue.cpp: clock_gettime(CLOCK_REALTIME, &timeout); src/libutil/SystemTimeSource.cpp: clock_gettime(CLOCK_REALTIME, &ts); src/libutil/SystemTimeSource.cpp: clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL); src/libutil/SystemTimeSource.cpp: int err = clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &ts, NULL); tests/systemtests/realtimetools.cpp: clock_gettime(CLOCK_REALTIME, &ts); tests/systemtests/realtimetools.cpp: clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL); tests/systemtests/realtimetools.cpp: clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &ts, NULL); tests/systemtests/test-clock_nanosleep.cpp: clock_gettime(CLOCK_REALTIME, &ts); tests/systemtests/test-clock_nanosleep.cpp: clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL); tests/systemtests/test-clock_nanosleep.cpp: int err = clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &ts, NULL); }}} There is that libutil/SystemTimeSource; I wonder why nobody is using it ... This also would be the place to check if CLOCK_MONOTONIC_RAW is available; not every kernel has it. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:16> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-23 08:39:54
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): Whoa, it seems that CLOCK_REALTIME is being used in almost every other location throughout FFADO. I guess that's what I get for changing things in bits of FFADO that up to now I haven't had a lot to do with. Hmm. This calls for some sort of central define I think to determine which clock to use. Of course, CLOCK_MONOTONIC_RAW can only be activated if a sufficiently recent libraw1394 is in place. I'll see about getting a suitable patch up soon. Stefan: thanks for the initial testing. I need to get the patched libraw1394 onto my development system to check this out further I think. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:17> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-23 09:29:08
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): There is a cut-and-paste recipe for getting libraw1394 from git at https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#libraw1394, but it should also be possible to apply the patch from linux1394-devel to a released libraw1394 source tarball. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:18> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-23 14:10:57
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): I have committed r2171. This should ensure that all timing-related parts of the FFADO streaming system reference the same clock source. Thanks Clemens for doing the obvious (a grep for CLOCK_ in the FFADO source) to highlight the fact that there were were more time calls than just the one related to the cycle timer. I've tested r2171 against an "old" libraw1394 and it doesn't appear to have caused any regressions under those conditions. I haven't had time to get a "new" libraw1394 onto this system yet and I'm out of time right now, so it remains untested on systems where raw1394_read_cycle_timer_and_clock() is available. Stefan wrote: > There is a cut-and-paste recipe for getting libraw1394 from git ... Thanks for the reference. > ... it should also be possible to apply the patch from linux1394-devel to a released libraw1394 source tarball That's the approach I intend to take. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:19> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-25 14:24:17
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): Thanks Stefan for the latest round of testing. I finally got a chance to put the latest libraw1394 (from git) on my development machine (it was easier doing that than merging patches) and thus was able to confirm your observations. I should note in passing that "ffado-test Discover" doesn't actually start the streaming threads. The timing errors you were seeing were from the cycle timer DLL which is started by libffado regardless of its mode of operation (which is why "ffado-test Discover" experienced them even though it doesn't do streaming). To cut a long story short, it turns out that clock_nanosleep() doesn't implement support for CLOCK_MONOTONIC_RAW at the kernel level and simply returns immediately (see kernel/posix-timers.c in the kernel source). This messed pretty badly with FFADO's timing in general and the cycle timer DLL in particular, as one might expect. There was no chance streaming could ever work in this scenario. FFADO svn r2172 addresses this problem; it simply uses CLOCK_MONOTONIC for the clock_nanosleep() call whenever FFADO's system clock source is set to CLOCK_MONOTONIC_RAW. With this in place I was able to confirm that streaming works once again with an RME FF800. Note that I've chosen to use CLOCK_MONOTONIC_RAW as the preferred system time source because CLOCK_MONOTONIC can still be slewed by NTP changes (CLOCK_MONOTONIC doesn't jump though, nor does it go backwards). Therefore to my eyes CLOCK_MONOTONIC_RAW would appear to be the better source of "system time" for FFADO. Please re-test with r2172 or later on your system with the problematic clock to see if, after all these false starts, we are any closer to making FFADO less susceptible to NTP-induced clock changes. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:20> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-25 22:20:57
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): r2174 is alas still unable to start [replaced keyboard, still practicing] -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:21> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-25 22:29:24
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): PS, it's the same whether ntpd is on or off. To eliminate all other factors, I tried - r2166 without ntpd - r2174 with ntpd - r2174 without ntpd - r2166 without ntpd - r2174 without ntpd - r2166 without ntpd and got consistent results: r2166 works, r2174 does not. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:22> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-26 11:11:53
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by jwoithe): Hmmm. It gets trickier now because I can no longer reproduce the problem on my system (r2174 without ntpd works fine with the RME FF800, libraw1394 git from last night, kernel 3.2.4). To be sure I just re-ran it again. You're still seeing the CycleTimerHelper negative step errors, which is pretty much exactly what we saw prior to r2172. On my system this was caused by clock_nanosleep(CLOCK_MONOTONIC_RAW,...) returning without delay. The continued existence of timing errors would ordinarily suggest that the driver you're using (DICE) calls a clock function directly which doesn't utilise the official system clock (giving rise to a clock value mismatch). However, as far as I can tell this doesn't happen, so I'm quite puzzled. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:23> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-06-26 12:01:10
|
#242: ntp interferes with ffado ------------------------+--------------------------------------------------- Reporter: ppalmers | Owner: ppalmers Type: bug | Status: new Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO 2.0-rc2 (1.999.42) Resolution: | Keywords: Device_name: all | ------------------------+--------------------------------------------------- Comment (by stefanr): The tests with r2166 <-> r2171 in comment 15 were done with the DICE driver (Focusrite Saffire PRO 24), but the tests with r2166 <-> r2174 in comment 22 were done with the BeBoB driver (Terratec PhaseX24FW). I shall repeat the latter with the DICE driver/ Saffire. -- Ticket URL: <http://subversion.ffado.org/ticket/242#comment:24> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |