[LAU] No more PCI!

[Pieter Palmers]

Paul Davis wrote:
> On Sat, Jan 30, 2010 at 12:38 PM, Pieter Palmers <pieterp at joow.be> wrote:
>> Clemens Ladisch wrote:
>>> 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.
> 
> the problem here is that a device would need to be represented by two
> clients, not 1, in order to minimize latency.
> of course, one could imagine, with the recent discussion on
> multiclient apps on the jack ml, that this is actually precisely how
> it should
> all work:
> 
> 1) jack starts
> 2) jack detects device existence
> 3) app is launched that creates
>        (a) one in-process client for input, if appropriate
>        (b) one in-process client for output, if appropriate
> ....
> ...
> 4) app detects device removal, shuts down - appears to other clients
> like a normal client vanishing from the graph
> 
> 
> this all sounds great except for one little technical implementation
> detail: JACK needs something to *drive* the graph.
> this is why the driver "client" has a special place in JACK's heart.

The backends could still be special clients that have a split 
read/process/write execution order.

Isn't it as simple as:

wait for 1 / read from 1
wait for 2 / read from 2
run graph
write 1
write 2

One challenge is phase sync, but that should be solved on the driver 
layer anyway.

> 
> however, now that this idea has been raised so clearly by pieter, i
> can imagine a way to do all this, rather cleanly. it needs thought,
> and should probably be on the JACK ML.

Maybe take into account that the firewire driver will most likely end up 
to be an ALSA driver. And that device aggregation (if not done in jack 
itself) will be done with the relevant ALSA mechanism. So it might be 
interesting to think about supporting this for ALSA devices in general. 
It might also be interesting for USB clients. Or if you have a firewire 
device that is synced with your PCI soundcard.


Greets,

Pieter