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