On Wed, 2008-02-06 at 13:30 +0200, Juuso Alasuutari wrote:
> In my opinion, LASH shouldn't communicate with JACK using the "normal"
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
LASH isn't special; it's just another application that wants to connect
> Some of the issues with the current libjack API are lack of engine and
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
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
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
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
Not that I recall.
Linux-audio-dev mailing list