[PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15

[Kjetil S. Matheussen]

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.




--