Re: [FFADO-user] Problems with libbfado version and jack

[Jonathan W. <jw...@ju...>]

Hi Stefan

On Fri, Mar 30, 2012 at 02:15:40AM +0200, Stefan Richter wrote:
> On Mar 30 Jonathan Woithe wrote:
> > The problem is probably related to the recent FFADO API version bump. 
> > Earlier jack versions insisted on an exact match of the API version even if
> > it is possible for them to run with newer versions (a situation which has
> > been since corrected).  The practical upshot is that jack revisions older
> > than 1 or 2 weeks will currently not run with newer FFADO versions.
> 
> But would an older jack run with current FFADO after been recompiled
> against current FFADO?  (I for one used to use stock Gentoo's jack 1,
> currently at revision 0.122.3, together with svn checkouts of FFADO.)

No it won't run, that's the problem.  In the jack backend code the test for
API version was for equality with the one which happened to be current at
the time that code was written (ie: 8).  Now that libffado advertises an API
version of 9, all older jack revisions will reject FFADO as incompatible.

The check being discussed is a runtime check based on the API version
returned from FFADO's ffado_get_api_version() function.  See lines 758ff in
drivers/firewire/ffado_driver.c of a current jack source tree.

What I'm thinking of doing is making libffado report an API version of 8
when it detects that it's being compiled against an older revision of jack.
When run on that system jack will then happily use the new libffado.

The current version of the firewire backend in jack now tests for an API
less than 8 and will only reject those.  This assumes that future changes to
libffado's API will be backwards compatible (as is the one from 8 to 9), but
I think that's reasonable.

> > I'm toying with an idea to make FFADO revert the API version it reports when
> > compiled against an older jackd.
> 
> Isn't jack compiled against FFADO rather than FFADO compiled against
> jack?

Correct.  However, the API version check being done by jackd is a runtime
check based on the value returned by ffado_get_api_version().

> IOW you consider to put application version checks into a library
> (because forward compatibility did not exist in the application until
> recently)?

Not exactly.  All I want to do is make libffado return an API version of 8
at runtime if was compiled on a system with an older version of jackd. It
means the new features of API version 9 won't be available, but since the
older jack versions didn't make use of them this isn't of practical concern.

I agree it's a bit of a hack, but having to talk users through a jack
upgrade on their systems just so they can test the latest svn snapshots of
FFADO is going to be *really* painful.

> And what happens if FFADO was build to lie about its version in this way,
> and then a recent non-buggy jack is built or installed from a binary
> package?

Things will continue to work as they did before, and any bug fixes in jack
would be immediately available.  The only impact would be that the newer
features of FFADO API 9 wouldn't be available until FFADO was recompiled,
and thus the feature-set of the newer jack would reflect that available with
the old until a FFADO recompile.

I should note here that the change between FFADO API 8 and 9 is the addition
of a function call which allows FFADO to support the setbufsize
functionality of jack.  Up to and including API 8 FFADO simply didn't
support this (if anyone tried it would simply flag that the operation
couldn't be done).  In practice, not having this feature is of little
consequence to most people because only a few utilise the dynamic resizing
of jack buffers while jack is running.

Regards
  jonathan