On Thu, 2008-01-24 at 05:33 +0200, Nedko Arnaudov wrote: > Bob Ham <[EMAIL PROTECTED]> writes: > > > On Wed, 2008-01-23 at 19:44 +0200, Juuso Alasuutari wrote: > >> I'm getting the feeling that there have been some misunderstandings in > >> this > >> discussion. Let's see if I can help with them, or if I'll just end up > >> confusing things more. :) > >> > >> On Wednesday 23 January 2008 00:18:48 Bob Ham wrote: > >> > On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov wrote: > >> > > Bob Ham <[EMAIL PROTECTED]> writes: > >> > > > More generally, LASH isn't a frontend for JACK. > >> > > > >> > > What about the jack watchdog? What does get killed by it? > >> > To try and work around a crash in jackd and present a system to the user
> >> > where crashes make no difference is to invite more problems. If you > >> > can't get jackd to stay up, what makes you think you can get your new > >> > system to stay up? > >> > >> I don't think Nedko's proposal is motivated by a desire to work around > >> existing bugs. > > > > It sounded suspiciously to me as though that was exactly what Nedko's > > proposal was :-) > IMHO, jack watchdog is feature, not bug. And yes, LASH needs a way to > handle it. Of course it needs to handle it. It needs to cleanly shut down due to the catastrophic failure. That's very different from creating a layer betwen JACK and the LASH clients where the catastrophic failure is glossed over. > >> > To view LASH as the centre of a linux audio system is to misunderstand > >> > its purpose. It might be able to *facilitate* a unified system, along > >> > with JACK and other APIs, but it isn't the unified system itself. Such > >> > a role is intended for the much-loathed "server interface" distinguished > >> > in the LASH API. > >> > >> I personally don't see LASH as the centre of the audio system, and I'm not > >> sure that Nedko meant to say that either. > > > > I must have been thrown off by Nedko's words "LASH should behave like > > all-in-one app" ;-) > > From user perspective, yes. lash + patchage like app. Well, more accurately it would be patchage-like-app + lash + jack + alsa + x11 and, if you're going to get networking in on the game, + ssh. You can see that lash is just a small part of such a system. The key issue becomes the patchage-like-app. > > IMHO, there is a lot of work to be done to properly provide the kind of > > support that LASH is *trying* to provide, without going on and thinking > > about what else it might be able to do. > > 0.6 > > Redesign client/server communication > > Certificate based security/encryption > > Use OSC > > Rework API > > Genericify patch-system specifics > > Provide more useful event system (callbacks, etc) > > Rewrite client library in gobject > > Rewrite server in C++ > Some thoughts regarding your 0.6 wishes: > > UDP OSC is one of the evils of current implementation. Current implementation of what? Regardless, the transport that's used isn't particularly important; you can just use TCP if UDP is an issue. Or fix the UDP transport. > certificates? encryption? really? For 0.6? o.0 > Overengeneering? Possibly. However, I think it's a good idea to have it included at the start of any redesign of the communication system. > I dont think using gobject is good thing in this case, because of the > KDE/GNOME schism. Just because the library is written using gobject, doesn't mean clients have to be. It's now trivial to run a QT main loop and glib main loop together: http://developer.kde.org/documentation/tutorials/qtgtk/main.html > I do agree about "Provide more useful event system (callbacks, > etc)". However, it is important not to break current API, but extend it > or provide alternative API. I also agree with Juuso, that fixing the API > can (and probably will) be made after we fix the more important things. I think it's important *to* break the current API due to its many issues. Why do you think that backwards compatibility with the current API is important? Bob -- Bob Ham <[EMAIL PROTECTED]> _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
