On Wed, 22 Jan 2003, Paul Davis wrote:
> >> why? given that we have not even finished the initial implementation, why? > >> > > > >1. I didnt' use much time on this. It was made most to test my new libaipc > >library. Its not at all complete either. > > why release it? > I guess that might a bit stupid. A show off. But my opinion is that jack doesn't perform very good, and by releasing k_jack, I try to prove it. Its a much better argument than just saying; I get lots of xruns and pops and clicks whatever I do. > >2. It was a provocation. :) > > > >For two years (or somethings), people have complained about the bad > > JACK hasn't existed for much more than a year. and like others here, i > haven't seen complaints about JACK's performance. Well, there have been reports about xruns. And, remember the resent discussion with the wine-guy that couldn't get it to run reliable without being root or have the capabilities patch? > i have seen reports > of system lockups (most of which seem traceable to ALSA), and there > have in the past been some very tricky IPC issues to solve when > clients go away. > > >performance of the jack system. And I don't think it has been solved. I > >dont know about alsa; and doesn't understand the driver-code, so it was > >easier for me just to reimplement jack. > > > >k_jack performs okey. You dont have to run things with realtime priority. > > this is a joke, right? you **cannot** get reliably low latency > performance on a linux system without SCHED_FIFO or SCHED_RR. i don't > care how you write it, it just won't work. > Perhaps we have a different opinion about what is reliable performance then. I dont care if I hear a click or a pop every second hour. It can be important in some situations, but in that case you should run with realtime priority. > >3. As I wrote in the README file. Its very simple when you can controle > >everything from PD. You could do this with the current implementation of > >jack, if you could make jack run without a driver. A dummy-driver is > >needed. > > then why not write that instead of divert people's attention with a > new implementation. > Yeah, I'm planning to. Havent got that far. > i find this all very upsetting. you write what appears from its name > to be some kind of IPC library. you decide to test it out. instead of > coming to jackit-devel and saying "i have this cool new library for > IPC. what do you think about using this to fix some problems with > JACK?", Oh sorry, I dont beleive the problem is with jacks IPC implementation (that would be quite unlikely I imagine), but rather the alsa driver. Hmm, guess I could be wrong, though. > you go ahead and partially reimplement JACK, potentially > causing a code fork when we haven't even quite finished the initial > implementation. i have great respect for the audio work you've done so > far, but this is really irritating. i would welcome patches, > redesigns, suggestions, insights into improving JACK, but > reimplementation when you don't even understand it all is just beyond > my sense of what is sensible. there's nothing to stop you from doing > this - this is all open source of course. but i sincerely hope that > people will not use this new implementation unless it can be shown to > have all of the features and less of the drawbacks of the initial one. > I didnt think that far. Remember, it was made on a day. Its very simple. I dont think or hope it will make a code fork. But, its fine for running freqtweak within pd, using 64 frames code blocks, as a normal user. I'm not even near the ability to that with jack. --