Bug#565342: newly released libffado2-based jackd fails with "firewire ERR: Could not start streaming threads: -1"

[Adrian Knoth]

On Fri, Jan 15, 2010 at 03:00:57PM +0100, Jonas Smedegaard wrote:

> Hi Adrian,

Hi!

>> Finding the right value(s) for p (and n) could be a hard job, so  
>> playing with those might be useful.
>
> Are you suggesting to shoot in the dark for magic combinations here, and  
> that _both_ too low and too high values lead to same error messages?

Absolutely. Larger unfortunately isn't better here. You are right that
larger period sizes normally give the driver more time to complete its
work.

With firewire, it's crucial to provide a stable ISO streaming to the
device, and when you increase the buffer size, packets are sent less
frequently. Together with jittered timing, the device might had run out
of packets, thus giving the typical xrun.

This behaviour will go away when FFADO moves to kernel space and can
rely on interrupts from the firewire host controller. This guarantees to
be woken up by hardware as soon as possible, but since FFADO is
userspace at the moment, having too large buffers could mean too long to
wait to get send and receive streams correctly aligned. (this is the dry
running state, a warm up phase taking place before actual operation to
tune both ends (the host and the device) to their specific timings)

On Juju, I usually operate my device at -p 512 and -n3 (which is the
default). When I omit -p (in other words: use the default 1024), I see
xruns and less stable operation.

However, unless -p is extremely small, every value should at least be
able to put the device into running state.

If not, this might be caused by underlaying timestamp errors, which are
mostly due to broken controllers.

You could increase -v to let's say -v5 to get more details.

If need be, file a ticket at subversion.ffado.org



HTH

-- 
mail: adi at thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver