[LAU] [FFADO-devel] No more PCI!

[Clemens Ladisch]

Pieter Palmers wrote:
> Clemens Ladisch wrote:
>> Pieter Palmers wrote:
>>> 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.
>> 
>> If Jack cannot fix a xrun immediately by restarting, it dies.  If the
>> device stays unplugged, waiting indefinitely for it to reappear would
>> make no sense.  This cannot be handled without asking the user.
> 
> To me it makes perfect sense. I unplug the device, jack keeps running in
> "dummy mode", I re-plug the device and we're good to go. Why would jack
> have to die? Even more: I plug in another device and it shows up as a
> new interface in the jack graph. Just like what happens if I start a new
> jack client.

So re-plugging can be handled mostly like a new device appearing.  This
means that the driver doesn't need to have support for this.  (Good for
me. :-)

> [...]
> Personally I would not mind to use ALSA for all the streaming (and mixer
> control for that matter) if it is up for it. The user support of
> parallel implementations is simply too much work. But it might take some
> time for that to happen (as we also have e.g. MOTU and RME streaming
> protocols to take care off).
> 
> The same goes for mixer control and maybe even device discovery: if it
> can be built upon ALSA, why not? I'm personally a bit skeptical about
> whether you'd want (or get) the required code for this into the kernel
> though. Especially for BeBoB devices its a significant.

The discovery/mixer code for USB and HDA devices is already in the
kernel, and it's just as messy.

However, if that code already exists (in userspace), I wouldn't want to
duplicate it without a good reason.


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

Now with playback, but still very experimental; Jack should work.


Best regards,
Clemens