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)...
-- Fernando
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:
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.
Greets,
Pieter
>
> $ 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