Ticket #242 (new bug)

Opened 2 years ago

Last modified 2 years ago

ntp interferes with ffado

Reported by: ppalmers Assigned to: ppalmers
Priority: major Milestone: FFADO 2.1
Component: Version: FFADO 2.0-rc2 (1.999.42)
Keywords: Cc:
The device the bug applies to: all

Description

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

Change History

05/23/10 06:51:52 changed 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 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.)

05/24/10 08:38:52 changed by stefanr

Affected:

jackd + ffado + linux1394

jackd + ffado + juju

Not affected:

jackd + alsa