[FFADO-devel] Compiling jack with new firewire driver against old libffado (was: Re: Jack2 svn error message)

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

Hi guys

[ jack-devel added since this issue affects jack as well as jack2 ]

On Mon, Mar 19, 2012 at 10:54:29PM +0100, Albert Graef wrote:
> On 03/19/2012 05:15 PM, Adrian Knoth wrote:
> >If you just want to compile the code without upgrading FFADO, I guess it
> >might be enough to add something like
> >
> >extern "C" int ffado_streaming_set_period_size(ffado_device_t *dev,
> >                          unsigned int period);
> 
> Does that mean that older FFADO revisions already have this function
> but it's not declared in the header files? Then this would indeed be
> the simplest solution.

No, older ffado revisions do not include this function.  It is new with
FFADO API version 9.

> Otherwise, Jack2 uses waf, so it should be easy to check for that
> routine at configure time.

That's what I'm thinking.  Do a configure-time test for the
ffado_streaming_set_period_size() function and include the setbufsize code
only if it's present.

I guess the other option is to make the FFADO API version accessible at
compile time via a global define.  It would certainly be easy enough to do,
and jack/jack2 could then directly test for the required API version.  The
only issue I see with this is that in the past there's a clear preference in
the jack codebase to test for features rather than versions, so I'm not sure
whether this solution would be acceptable.

If the provision of a define from FFADO is acceptable, I could trivially add
it.  Then the code in jack and jack2 would end up being something like

  #if FFADO_API_VERSION > 8
  <code that uses ffado_streaming_set_period_size()>
  #endif

When compiled against older versions of libffado the conditional define will
evaluate to false and the code calling the new function won't be called.

FFADO_API_VERSION already exists in an internal ffado header file, so it
would just be a case of working out a way to propagate this into ffado.h.

Let me know what the preferred course of action is.

> In any case, it would be nice to have the latest Jack2 continue to
> work with the older revisions IMHO. ...

I agree.  It should be noted that binary versions of the new jack should
work because ffado declares the new function using weak linkage.  If one's
libffado doesn't include ffado_streaming_set_period_size() jackd will still
run.  The test for the ffado API version in jack's ffado_driver_bufsize()
function protects against the older version of libffado.  However, none of
this addresses the issue of compiling a new jack against the old ffado.

Regards
  jonathan