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: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers