[LAD] Summercode 2008: LASH, pt. 3

Juuso Alasuutari juuso.alasuutari at gmail.com
Wed Feb 6 11:30:38 UTC 2008


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?

I apologise for the sloppy language I used. I should've specified that 
with 'libjack' I'm referring to what libjack is at the present moment. 
In my opinion, LASH shouldn't communicate with JACK using the "normal" 
client lib. It goes against the concept (LASH is special; it's not your 
generic audio application), and it has its limitations.

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, and the practical requirement that a port 
connection frontend be RT capable. (I've understood that the last one 
doesn't apply to libjackmp, though.)

Most of these would be solved by a control interface to JACK, which is 
something that LASH should use. 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.

I'm starting to get a feeling that what I just said isn't all that new. 
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? (What goes around, comes around.)

Juuso



More information about the Linux-audio-dev mailing list