[LAU] [FFADO-devel] [ANN] FFADO 2.0 Release Candidate 1 (1.999.40) available

[Jack O'Quin]

On Mon, Nov 24, 2008 at 2:24 AM, Pieter Palmers <pieterp at joow.be> wrote:
> Jack O'Quin wrote:
>>>
>>> On Sun, 23 Nov 2008, Pieter Palmers wrote:
>>
>>>> The FFADO team is proud to announce the first release candidate for
>>>> FFADO 2.0.
>>
>> I just tried the new libffado-2.0-rc1 with jack 0.113.3 (SVN) with my
>> PreSonus FireBox on Ubuntu Hardy with the 2.6.24-21-rt kernel.  The
>> ffado-diag script says I have the old 1394 stack.  Is that a problem?
>> If so, how do I get the new one?
>
> The old stack is exactly what you need.
>
>> The libffado.so got built and installed, but the JACK firewire backend
>> could not find it, because ldconfig was apparently not run.  So, I ran
>> ldconfig by hand.  Also, I notice there is no library versioning, yet.
>>  Is that intentional?
>
> Good question. Do you have any suggestions on how we should be doing it? I
> remember that someone tried to do it, but didn't succeed.

The traditional way is to use libtool version numbers.  The idea is to
give the library a three-part number reflecting: (a) the current
interface version; (b) minor compatible updates to that version; and
(c) an indication of how many previous versions are also supported.
It's basically a binary compatibility scheme.  The loader can compare
the library version with that used by a program linking to it.  If the
versions are compatible, then that library should work.  The idea is
simple, but the details are quite messy and confusing...

  http://www.nondot.org/sabre/Mirrored/libtool-2.1a/libtool_6.html
  http://www.ensta.fr/~diam/dev/online/autoconf/autobook/autobook_91.html

There is native support for all that in the automake, autoconf
toolset, which leaves the question of how to do similar stuff in
SCons.  I am just beginning to use SCons on another project, and
coincidentally I wanted to do libtool versioning for it only last
week.  I was unable to come up with a quick solution.  The native
SCons SharedLibrary() method does not obviously support it.  I didn't
spend much time researching the matter, however.

SCons is a good tool, and is becoming popular.  Surely many people
have already solved this problem by now.

>> After fixing that, I am still unable to start JACK.  I tried resetting
>> the bus via gscanbus, but it still does not come up.  I am attaching
>> the ffado-diag output and the ffado-jack.log.
>
> You are suffering from hostcontrolleritis. The O2 micro controller has some
> issues that cause it to stall under certain conditions.
>
> There are few things that can help:
> 1) applying the cycle skip patch to the 1394 kernel sources:
> http://subversion.ffado.org/wiki/TxSkipPatched
> 2) decreasing the amount of kernel space buffering will result in
> this being less likely to occur. You can specify a config file:
> http://subversion.ffado.org/wiki/ConfigFile
> Setting the max_nb_buffers_xmit to 32 (or lower) should help. Note however
> that this will result in a higher sensitivity to xruns since this means that
> userspace has to refill the buffers every 32/2*8 frames.
>
> Probably the best solution is to get a better host controller.

OK.  Thanks for the help, Pieter.

I'll look for a decent PCcard controller.  They probably don't cost much.
-- 
 joq