22 Jan
2008
22 Jan
'08
12:56 p.m.
On Tuesday 22 January 2008 15:39:20 Nedko Arnaudov wrote:
Juuso Alasuutari <juuso.alasuutari(a)gmail.com>
writes:
I didn't quite understand what you mean by this until I read onward. Are you
referring to capturing clients' output, like you mention below?
- Turn LASH into a D-Bus service daemon.
Do you mean lashd becoming a D-Bus service? If so, do you imagine
having logfile like of jackdbus? I think it is quite important what will be changes for
users of
LASH. The things you mentioned are changes either to internal
implementation or API. IMHO, all changes should be driven by desire to
solve current problems that LASH user have (as human using the whole
thing, not as API user). Thus problems that people have with LASH should
be taken into account. Here are my problems with LASH:
* auto-launching without logfile means no proper handling of lashified
apps stdout/stderr. It should have logfile, with prefixing output of
apps.
Capturing the clients' debug messages would indeed be helpful. How do you
think it should be handled?
One option would be to add a logging method to the API that the clients should
use. But as with most other client requirements, there's no way to control
that they actually behave correctly (think of loading and saving files
correctly). And even if they do, then what about other messages than those
deliberately put into the code, like e.g. GLib errors?
Idiot-proof capturing of stdout/err could probably only work if the client
process was executed from a wrapper. It could be accomplished with the D-Bus
service file, though. If all clients' service files would be mandated to
include something like "Exec=/usr/bin/lash_exec /usr/bin/foobar", then...
Umm, at least we could redirect the streams _somewhere_ -- but what to do
from thereon, I'm not sure.
* lash is of mercy of libjack and crashing jackd
often causes lashd
kill. This is just wrong. lash should be able to restart jack, tell
jack apps that jack server is started again so they can reconnect to
jack server and finally lash can restore jack connections.
* lash should preserve at least basic properties of currently started
JACK server, such as sample rate and availability of hardware
ports. When loading session whose JACK parameters dont match, user
should be given options what to do.
This is where I believe we both agree that turning LASH into a D-Bus service
will help. The session handler shouldn't be a JACK client; instead, the audio
server should be a D-Bus client of the session handler, although a Very
Special one. And that's something that the JACK D-Bus control interface will
enable.
* there is no export/import "tarball"
(single file) functionality, to
be used for backup of sessions and transfering them between machines
* lash apps should be allowed to do "light save", with app session
referecencing files/resources external to lash. This means for
example that such lash light save should not copy ardour wav files
that are linked (not copied) to lash directory.
These sound like they could be useful features. However, I feel that we should
settle on the more basic issues first.
* lash should be able to manage not lashified apps at
least to extent
of launching them and connecting their ports.
I'd say this sounds OK.
* there is no good GUI for controlling lash. probably
[wm]glashctl
fixes this. lash_panel use is PITA. Usable GUI should be part of the
lash tarball. Also, X11-less operations should be still possible
(command-line or ncurses).
None of my business... :) (On the other hand, it's important to distinguish
between features which only concern the UI and those that affect API design.)
* lash does not preserve X11 related properties of
apps, like on what
screen (dual-head) they were.
Are you really sure that this one is worth the effort? Sounds to me like an
awful long detour from managing audio sessions.
* when opening/importing session, lash should be able
to either replace
current session or merge it, to allow combining several simpler
sessions into more complex ones
This is high tech, and as such it sounds tempting. Too tempting to be
considered at this point.
Things that I'm not personally interested on (I
don't think they worth
but there is nothing wrong if support for them is there, unless this
makes implementation much more complicated and thus bug-prone):
* Supporting connections for things other than JACK (read ALSA seq)
The current LASH already handles ALSA Seq connections, and I think it's fair
that the D-Bus implementation would, too.
* Supporting multi machine sessions (several machines
in a network used
in common session).
* Creating "universal" fit-all solution that works for every single app
on every single OS and thus, not being able to it at all using
available resources. This does not mean that support for other OS-es
should be avoided intentionally. Still, I need *Linux* Audio Session
Handler, not LASH Audio Session Handler.
Please, you're confusing me. ;)
I plan to donate my time to fixing LASH, after I (with
Juuso's and
Marc's help) finish with jackdbus (patchbay and transport control
interfaces are still mising). I'd like everybody who has problems with
current state of LASH to write them in this thread.
I plan to continue working on jackdbus which is an important part of this
whole scenario. But until the winning applications are announced I'll refrain
from any actual LASH coding; I need to know the level of commitment I can
afford to make before I take on a task this big. I will need to hash things
out on a conceptual level beforehand though, as it's hard to pull a realistic
and credible development plan solely out of one's back pocket.
At this point I believe it would help to categorize the different sub-goals.
What issues are purely in the domain of API design, what are the things that
the daemon must handle, etc. I'll start sketching these and getting familiar
with what we have now, then post some sort of rough draft. In the meantime
I'll be happy if anyone wants to comment on the questions above.
Juuso