Re: [LAU] [LAD] Summercode 2008: LASH as a D-Bus service

Juuso Alasuutari <juuso.alasuutari@email-addr-hidden> 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
   apps.
 * 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>

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user