Re: [Jack-Devel] backend switching - another way

PrevNext  Index
DateTue, 22 Feb 2011 08:35:25 +0100
From Arnold Krille <[hidden] at arnoldarts dot de>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToPaul Davis Re: [Jack-Devel] backend switching - another way
Follow-UpPaul Davis Re: [Jack-Devel] backend switching - another way
Hi,

On Tuesday 22 February 2011 02:57:58 you wrote:
> On Mon, Feb 21, 2011 at 5:33 PM, Arnold Krille <[hidden]> wrote:
> >> There is a fundamental difference: the backend is what you wait for
> >> to start a cycle, it's the first to be read and the last to be written.
> > 
> > Yep, so the backend is a client that is master-clock-capable. Other then
> > that its a normal client with ports and a processing-callback. Just give
> > it a callback or something appropriate to run as master and otherwise
> > tell it when it is not running as master.
> 
> if you take a look at the internals of torben's alsa_in and alsa_out,
> i think you'll see that there is a bit more to it than that :)

I was waiting for that. Yes, it is more then that. It also has resampling to 
care for unmatched samplingrates and not-synchronized devices. (If there is 
even more, please tell me. Not everyone of us has days to spend looking 
through other peoples code.)
Does that mean that my idea/vision is sunk?
Why not make that resampling available to other clients as well? A firewire-
client or an avb-/rtp-client would very much like to reuse the resampling-code 
without duplicating it. And both would also be able to control jacks clock if 
they where the only hardware-client running.

Have fun,

Arnold

PS: Sorry if I keep on insisting on this idea of mine. Unless you give me good 
arguments like "its never going to happen in any jack we release" or "we 
accept your patches but we won't think about implementing it ourselfs" I 
currently see no reason to stop my thoughts.
PrevNext  Index

1298360147.6574_0.ltw:2,a <201102220835.29917.arnold at arnoldarts dot de>