Re: [LAU] No more PCI!

From: Pieter Palmers <pieterp@email-addr-hidden>
Date: Wed Jan 27 2010 - 08:32:57 EET

Clemens Ladisch wrote:
> 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).

Thanks for the repo, I'll check it out tonight.

Talking about mixer controls: do you intend to expose all mixer controls
to ALSA, or would a custom application still be the way to go for
mixers?. Can ALSA handle mixer capabilities that change with changing
device configurations?

>
>> 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?

With the current version of FFADO this is not possible as bus resets are
not handled properly. But there is no technical reason that prevents
this. Jack ports can be created and destroyed at run-time, and that's
all it takes.

The major use-case I'm thinking of is where a user inadvertently unplugs
the device. With current FFADO this is a show stopper, but I'd like to
see a system that keeps running and restores everything once the device
is re-attached.

>
>> So maybe you should worry more about the confusion that might cause...
>
> While potential users might disagree, I think more choice is better.

Most likely users won't care as long as it works (at least that's how I
look at things I didn't develop myself). The challenge will therefore be
to ensure that both systems can co-exist.

Greets,

Pieter
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Wed Jan 27 12:15:01 2010

This archive was generated by hypermail 2.1.8 : Wed Jan 27 2010 - 12:15:02 EET