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 |