[LAU] [FFADO-devel] [ANN] FFADO 2.0 Release Candidate 1 (1.999.40) available
nando at ccrma.Stanford.EDU
Wed Dec 10 21:47:02 EST 2008
On Mon, 2008-11-24 at 09:24 +0100, Pieter Palmers 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.
Is it possible to make it work with the new stack? Could I send you
information to try to debug that?
With the old 1394 stack I just managed to get an Edirol FA-101 to work
under Fedora 10, but the newer stack in Fedora's stock kernels does not
get that far (it tries but fails)...
> > 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.
> > 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:
> 2) decreasing the amount of kernel space buffering will result in
> this being less likely to occur. You can specify a config file:
> 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.
> > $ jackd -Rv -P70 -d firewire -v6 -r48000 -p1024 -n3 2> ffado-jack.log
> > getting driver descriptor from /usr/lib/jack/jack_freebob.so
> > getting driver descriptor from /usr/lib/jack/jack_oss.so
> > getting driver descriptor from /usr/lib/jack/jack_firewire.so
> > getting driver descriptor from /usr/lib/jack/jack_net.so
> > getting driver descriptor from /usr/lib/jack/jack_alsa.so
> > getting driver descriptor from /usr/lib/jack/jack_dummy.so
> > jackd 0.115.3
> > Copyright 2001-2005 Paul Davis and others.
> > jackd comes with ABSOLUTELY NO WARRANTY
> > This is free software, and you are welcome to redistribute it
> > under certain conditions; see the file COPYING for details
> > JACK compiled with System V SHM support.
> > registered builtin port type 32 bit float mono audio
> > registered builtin port type 8 bit raw midi
> > clock source = system clock via clock_gettime
> > start poll on 3 fd's
> > loading driver ..
> > new client: firewire_pcm, id = 1 type 1 @ 0x806ea80 fd = -1
> > new buffer size 1024
> > registered port system:capture_1, offset = 4096
> > registered port system:capture_2, offset = 8192
> > registered port system:capture_3, offset = 12288
> > registered port system:capture_4, offset = 16384
> > registered port system:capture_5, offset = 20480
> > registered port system:capture_6, offset = 24576
> > registered port firewire_pcm:C6_dev0_MidiIn, offset = 4096
> > registered port system:playback_1, offset = 0
> > registered port system:playback_2, offset = 0
> > registered port system:playback_3, offset = 0
> > registered port system:playback_4, offset = 0
> > registered port system:playback_5, offset = 0
> > registered port system:playback_6, offset = 0
> > registered port system:playback_7, offset = 0
> > registered port system:playback_8, offset = 0
> > registered port firewire_pcm:P8_dev0_MidiOut, offset = 0
> > ++ jack_sort_graph
> > ++ jack_rechain_graph():
> > +++ client is now firewire_pcm active ? 1
> > client firewire_pcm: internal client, execution_order=0.
> > -- jack_rechain_graph()
> > -- jack_sort_graph
> > starting server engine shutdown
> > stopping driver
> > server thread back from poll
> > unloading driver
> > freeing shared port segments
> > stopping server thread
> > stopping watchdog thread
> > last xrun delay: 0.000 usecs
> > max delay reported by backend: 0.000 usecs
> > freeing engine shared memory
> > max usecs: 0.000, engine deleted
More information about the Linux-audio-user