Re: [LAU] No more PCI!

From: Pieter Palmers <pieterp@email-addr-hidden>
Date: Sat Jan 30 2010 - 20:28:03 EET

Paul Davis wrote:
> On Sat, Jan 30, 2010 at 12:38 PM, Pieter Palmers <pieterp@email-addr-hidden> 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sun Jan 31 00:15:02 2010

This archive was generated by hypermail 2.1.8 : Sun Jan 31 2010 - 00:15:02 EET