On Mon, Nov 24, 2008 at 2:24 AM, Pieter Palmers <pieterp@xxxxxxx> 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
