[LAD] Summercode 2008: LASH, pt. 3

Bob Ham rah at bash.sh
Wed Feb 6 13:51:45 UTC 2008


On Wed, 2008-02-06 at 13:30 +0200, Juuso Alasuutari wrote:
> Bob Ham wrote:
> > On Mon, 2008-02-04 at 18:18 +0200, Juuso Alasuutari wrote:
> >> Fons Adriaensen wrote:
> >>> I fail the see the advantage of D-Bus over e.g. OSC via UDP or TCP.
> > 
> >> The core issue is abstracting the interfaces involved. As long as it
> >> serves to free LASH from being a libjack client
> > 
> > Why is freeing LASH from being a libjack client a goal?

> In my opinion, LASH shouldn't communicate with JACK using the "normal" 
> client lib.

The normal client lib provides control interfaces as well as "normal"
audio functionality.  There's no reason LASH shouldn't use the client
lib to communicate with JACK.

> It goes against the concept (LASH is special; it's not your 
> generic audio application), and it has its limitations.

LASH isn't special; it's just another application that wants to connect
ports. 

> Some of the issues with the current libjack API are lack of engine and 
> driver parameter controls, lack of control for stopping, starting, and 
> auto-launching JACK

Firstly, these are not things that LASH is concerned about.  It only
cares about JACK's client graph.

Secondly, as you note yourself, these are things lacking from the
libjack API.  If things are lacking from the libjack API, that is an
argument for adding them to the libjack API.  It isn't an argument for
removing libjack usage from LASH.

> the practical requirement that a port 
> connection frontend be RT capable.

If this is the case, then it's a bug in JACK.  Fix the bug.

> Most of these would be solved by a control interface to JACK, which is 
> something that LASH should use.

LASH shouldn't be controlling the JACK server; it should only be trying
to control the client graph.

> It could be a D-Bus interface that's 
> built into JACK or, preferably, the control interface could be a 
> separate library/API provided by JACK. This API could then be used to 
> implement a D-Bus interface, an OSC interface, and LASH could use it 
> directly.

Or, it could just use libjack, like it does at the moment.

> Of course it's not my idea -- it's been talked about on #lad many times 
> already -- but doesn't it resemble something that you suggested at some 
> point earlier on, Bob?

Not that I recall.

Bob

-- 
Bob Ham <rah at bash.sh>




More information about the Linux-audio-dev mailing list