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

On Mon, Feb 21, 2011 at 10:17:17PM +0100, Arnold Krille wrote:

> On Monday 21 February 2011 19:53:03 Fons Adriaensen wrote:
> > I've been musing for a long time over the idea 'what if Jack ports
> > were persistent' ? In other words, if they could exists irrespective
> > of the application that uses them is running or not.
> > 
> > This has some far-reaching consequences of course, but there is
> > subset of this idea that is not as mad as it seems (IMHO).
> > 
> > ** What if physical ports were persistent ? **
> 
> I like the idea!
> 
> Still I would like to extend the question: What if there where virtual ports?
> 
> These virtual ports would be configured in a configuration(-file) if present or 
> by the first client providing these. If no config-file was there to make the 
> ports persitent forever, they would stay as long as jack is running, 
> regardless of the backend actually in use.

I don't see much difference between your 'virtual' ports and the
'persistent' ones I proposed.

> I would very much like to remove the distinction between "clients" and 
> "backends". After all a traditional client (be it a separate process or an in-
> server-client) is just a client that is capable of free-wheeling.

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.

> and backend is just an in-server-client that is not (necessarily) free-wheeling 
> capable but definitely master-clock-capable.
> Thinking about it, even this is not true, the "null"-backend would be the 
> master-clock for freewheeling. Thus hardware-clients would be not-
> freewheeling-capable. And as long as all clients are either synced or at least 
> have resampling-capabilites (for unsynced hardware-clients), there is no 
> difference between clients and backends...

Freewheeling is an option. The 'default' backend (used when the official
one goes away without notice) should be the dummy one with the same sample
rate and period as the real one it replaces.

> Some benefits of this would be:
>  - Several backends running at the same time (like alsa-on-the-pci-soundcard, 
> alsa-on-usb-soundcard and firewire).

I don't see how you could have more than one at any time.

>  - Clients defining the "master-out" ports to provide some studio-monitoring-
> control before actually sending the data to whatever hardware there is.

Yes.

Ciao,

-- 
FA

1298325064.14546_0.ltw:2,a <20110221215050.GE23776 at linuxaudio dot org>