30 Jan
2010
30 Jan
'10
2 p.m.
On Sat, Jan 30, 2010 at 12:38 PM, Pieter Palmers <pieterp(a)joow.be> wrote:
Clemens Ladisch wrote:
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.
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.
--p
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.