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

[Paul Davis]

>Francois Dechelle wrote:
>
>>Could you be more precise on the 'complains about the bad performance of
>>the jack system' ? Without precise facts, I tend to consider these kind
>>of assumptions as just crap.
>>
>jack is not usable at all for a normal end user. without a low-latency 
>kernel there a pops and klicks everywhere. then jackd freezed my 

try running *any* linux audio program with 1024 frame interrupt
interval and a 2048 frame buffer. it won't be any different.

>different debian installations several times (this may kernel related, 
>but a user don't care when other programs don't freeze the machine). it 
>consumes rediculous amounts of memory (jackd uses 11MB, pd without gui 
> 1,2MB).

this is from a JACK instance that has been running on my system for
about 10 days:

paul     21401  0.0  0.0  1628  548 ttyp2    S    Jan21   0:00 jackd -v -d alsa 
paul     21402  0.0  0.2  9892 2576 ttyp2    S    Jan21   0:00 jackd -v -d alsa 
paul     21403  0.0  0.2  9892 2576 ttyp2    S    Jan21   0:00 jackd -v -d alsa 
paul     21404  0.0  0.2  9892 2576 ttyp2    S    Jan21   0:00 jackd -v -d alsa 
paul     21405  0.0  0.2  9892 2576 ttyp2    S    Jan21   0:00 jackd -v -d alsa 
paul     21406  0.3  0.2  9892 2576 ttyp2    S    Jan21   2:47 jackd -v -d alsa 

the VSZ field says that its using about 9MB, but only about 2MB of
that is actually resident. the gnomepager (as just one example) is
comparable in its use. most of that 9MB, as steve noted, is related to
potential IPC use, and is forced upon us by the granularity of shm
segments. 

>in general the idea  that pd is the audio server seems a little bit 
>weird, but if it's useful in special cases, why not?

because it forks the committment to a common interface (hence the need
to relink against a different libjack.

--p