19 Dec
2007
19 Dec
'07
5:56 a.m.
Fons Adriaensen <fons(a)kokkinizita.net> writes:
We have a nice app called jackd even if it doesn't
really
deserve the final 'd'. It works quite well. Please keep it
that way.
I'm all in favour of a control interface to jackd that is
separated from the audio client interface.
But so far I've failed to understand which useful features,
if any, this dbus stuff would add to jackd. If it's 'desktop'
related, please solve it at that level, but don't destroy a
well working application.
So you failed to understand how it works, thus how jackdbus differes
From jackd, and yet you think it should work in some other way? :D Or
I've misunderstood you?
Exactly the reason to not destroy existing well working application
(jackd) is the main reason I made jackdbus separate app.
The useful feature is one you mentioned, to separate control
interface. It also adds the logfile thing. Also it adds settings
persistence on jack side, so you dont need to have cryptic ~/.jackdrc
file, edited either by hand or by control app that needs to know what
jackd options are (moving target, also depends on drivers used).
Actually I think both settings persistence and logfile can be used by
jackd too, but this will probably not happen anytime soon. At least for
settings persistence, Paul told me once that it is probably post 1.0
(guess when is that :D).
I we had server lib, to be reused by both jackd and jackdbus,
jackdbus could be made completely separate app, it will not need compile
time access to jack sources. Unfortunately, I dont think this can be
made easily and in non-intrusive way.
Can you explain what you mean by solving things at desktop level?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>