Paul Davis wrote:
On Fri, Jan 22, 2010 at 3:13 AM, Clemens Ladisch
<clemens(a)ladisch.de> wrote:
Firewire devices are currently supported only by
FFADO (i.e., only with
Jack); I'm writing an ALSA driver for Echo devices right now, based on
my AudioFire2.
uh-oh. no chance we could convince you to instead help Pieter move the
streaming part of FFADO into the kernel so that it can be used by
ALSA? Apparently the core part of this has already been done.
Don't worry, we have already been communicating on this. I think its not
a bad idea to take things one step at a time. The FFADO codebase is not
really an example of elegance. It bears several signs of a learning
process, is (therefore) massively over-engineered, and is certainly not
suitable for kernel space (e.g. is C++, uses floats).
Furthermore the new firewire kernel stack presents an API that is much
better suited for bi-directional low-latency streaming. The current
FFADO streaming engine tries to work around the limitations of the old
stack, but as a result its architecture is not suited for the new
stack's API.
So a "move" of the streaming part of FFADO degenerates into a re-write
anyway. And rewriting just what is needed to discover the audiofire is a
better idea than trying to use FFADO for discovery from the start as the
audiofire discovery code can be fairly straightforward.
Once an ALSA streaming driver is available for the audiofire, it will
not be too difficult to adapt it such that it uses FFADO for device
discovery. This should make it work with all devices that use
IEC61883/AMDTP streaming (i.e. bebob, dice and oxford based devices).
I'm already restructuring the FFADO codebase to support an external
streaming engine. This should make it easy to glue things together once
the kernel driver is ready.
In any case I'm pretty happy that someone with ALSA experience takes on
the task of writing a kernel driver, because if I have to do it it would
probably take another two years.
Greets,
Pieter
PS: An ALSA driver for firewire devices will solve quite some issues
with respect to user experience and compatibility. Nevertheless I'm
personally still inclined to maintain and improve the userspace jack
streaming engine, and also port it to the new firewire stack. I'm not
convinced that things like hot-plugging, device aggregation and
sample-accurate midi will be easy to implement using
jack->ALSA->firewire. So maybe you should worry more about the confusion
that might cause...