Re: [Jack-Devel] jack1 version jack2 public headers comparison

On Mon, Feb 27, 2012 at 10:00:22AM -0800, Devin Anderson wrote:
> On Mon, Feb 27, 2012 at 1:16 AM,  <[hidden]> wrote:
> > On Sat, Feb 25, 2012 at 02:29:34PM -0800, Devin Anderson wrote:
> >> On Fri, Feb 24, 2012 at 9:44 AM, Stéphane Letz <[hidden]> wrote:
> >>
> >> > Le 24 févr. 2012 à 17:41, Paul Davis a écrit :
> >> >
> >> >>> Reworked :
> >> >>> ==========
> >> >>>
> >> >>> jackctl_server_start/jackctl_server_close reworked in a
> >> >>> jackctl_server_open/jackctl_server_start/jackctl_server_stop/jackctl_server_close
> >> >>
> >> >> seems reasonable, though what's the justification?
> >> >
> >> >
> >> > (Not completely sure anymore), but I think it was related to
> >> > slave backend management when Devin Anderson did the MIDI
> >> > backend rewrite in JACK2. This open/start/stop/close scheme
> >> > was a better way to separated the steps.
> >>
> >> See the last four comments on this ticket:
> >>
> >>     http://trac.jackaudio.org/ticket/219
> >
> > i fail to understand, why this justifies this splitup.
> > it seems that, in order to add slave drivers, the server needs to be
> > opened ?
> 
> IIRC, 'jackctl_server_open' instantiates the master audio driver.
> Calls to 'jackctl_server_add_slave' instantiate slave drivers, each of
> which is added to the master driver.

i dont see why slave drivers must be children of the master driver. 
but this is an implementation detail anyways. 

jack1 slave drivers are just a list of slaver drivers in the engine.


> 
> > and because the implementation is lacking support for adding slaves
> > while the server is running, you need to add them in between.
> >
> > the implementation in jack1 is equally bad. we even lack the controlapi
> > bits. however... i dont see why we cant just save a proper list of slave
> > drivers in the jackctl_server_t which are then instantiated during
> > server start.
> 
> AFAIK, there isn't really a reason, save that some of the internal
> structures would have to be changed in JACK 2.

implementation detail. i dont think it justifies an API change.

> 
> However, that doesn't mean your idea is necessarily better.  There
> would still need to be functionality to add and remove the master
> driver.  You could make the case that the calls could be renamed to
> 'jackctl_server_add_master' and 'jackctl_server_remove_master'.  Since
> the server requires a master driver to run, I think that the
> 'jackctl_server_open' and 'jackctl_server_close' names are just fine.

we already have a call that changes the master driver.

/**
 * Call this function to switch master driver.
 *
 * @param server server object handle
 * @param driver driver to switch to
 *
 * @return success status: true - success, false - fail
 */
bool
jackctl_server_switch_master(jackctl_server_t * server,
                            jackctl_driver_t * driver);


i think i begin to understand, what happened here:

- jack2 requires an instantiated master driver to be able to add slave
  drivers.

- its not possible to change slave drivers, while the engine is up and
  running.

The splitup of the control api seems to be a bandaid, which papers over
these problems with the implementation. 

IFF these 2 Problems would be fixed in the implementation (which is
really not so hard) would you still need this splitup ?



-- 
Mit freundlichen Grüßen
Torben Hohn

Linutronix GmbH

Standort: Bremen

Phone: +49 421 166 73 41 ; Fax.: +49 7556 919 886
mailto: [hidden]
Firmensitz / Registered Office: D-88690 Uhldingen, Auf dem Berg 3
Registergericht / Local District Court: Freiburg i. Br., HRB Nr. / Trade
register no.: 700 806;

Geschäftsführer / Managing Directors: Heinz Egger, Thomas Gleixner

1330538373.28854_0.ltw:2,a <20120229095711.GJ18457 at lxhb dot hb dot de>