[LAU] Phonic Helix Board 24 on Fedora
nando at ccrma.Stanford.EDU
Tue Feb 17 14:51:49 EST 2009
On Tue, 2009-02-17 at 19:45 +0100, Pieter Palmers wrote:
> Fons Adriaensen wrote:
> > On Mon, Feb 16, 2009 at 03:40:47PM -0800, Fernando Lopez-Lezcano wrote:
> >> The issue has nothing to do with the rt patch or running with -R, it is
> >> just the wrong (newer) firewire stack.
> > Hmm, is that the new fireware stack that Pieter
> > told me about (IIRC at the door of the LAC2008
> > LSN location) and that would actually allow to
> > simplify FFADO ??
> Indeed, that's the one. Unfortunately I didn't get around implementing
> FFADO support for it yet. Mostly due to lack of time. And because it
> does lack some features we need, which don't seem to be high on the
> priority list (e.g. support for multiple streams). Besides, the authors
> claim backward compatibility at the library level, i.e. libraw1394 users
> like FFADO shouldn't have to care.
My experience with this is that it currently does not work. Booting into
the new stack, even with libraw1394 2.x, breaks FFADO. It does work fine
with the old stack (same everything else).
> But shifting it all to the 1394 guys is not completely fair. I do admit
> that we are not very noisy towards them. I guess that once more distro's
> start using the new stack that will change.
> But almost a year has passed since LAC'08 and my views on the topic have
> evolved a bit. While from a theoretical perspective it should be
> possible to implement FFADO in userspace, there are some issues that
> make life a bit harder than it should be. And if it were only software
> things I could think about fixing them. But there are also some
> hardware-level issues that need workarounds that can't be done in
> userspace. If you want more details, I suggest we discuss that at the
> entrance of some obscure venue in Parma ;).
> The bottom line is that I am planning to, using the current FFADO
> codebase as a reference, port the streaming code to the kernel, with a
> direct interface to ALSA. That should bring a performance improvement
> too. And it will also lighten the burden of supporting the zillion audio
> API's Linux developers seem to need.
More information about the Linux-audio-user