Pieter Palmers wrote:
> ...
> 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.
BTW: a first version of the driver is available here:
git://git.alsa-project.org/alsa-kprivate.git fireworks
(this branch will be rebased)
At the moment, it has one fixed sample rate, no mixer controls, and
capture only (but playback already works in my even stupider userspace
test program).
> 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.
Hotplugging and device aggregation should work just fine, although not
both together, i.e., ALSA doesn't allow changing the stream format while
the stream is running. Is this possible with FFADO+Jack?
> So maybe you should worry more about the confusion that might cause...
While potential users might disagree, I think more choice is better.
Best regards,
Clemens
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Jan 26 12:15:02 2010
This archive was generated by hypermail 2.1.8 : Tue Jan 26 2010 - 12:15:02 EET