[LAU] [LAD] Summercode 2008: LASH as a D-Bus service
nedko at arnaudov.name
Tue Jan 22 08:39:20 EST 2008
Juuso Alasuutari <juuso.alasuutari at gmail.com> writes:
> - 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
* 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.
* 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.
* lash should be able to manage not lashified apps at least to extent
of launching them and connecting their ports.
* 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).
* lash does not preserve X11 related properties of apps, like on what
screen (dual-head) they were.
* 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
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)
* 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.
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.
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 188 bytes
Desc: not available
Url : http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20080122/ebcc3896/attachment.pgp
More information about the Linux-audio-user