Re: [linux-audio-user] This criticism of jackd valid?

On Sunday 21 January 2007 13:46, Chris Metzler wrote:
> As much more of a music maker than a developer, I'm not able to evaluate
> whether this post from a current thread on Slashdot is a valid criticism
> of JACK:
>
> http://ask.slashdot.org/comments.pl?sid=217898&cid=17700570
>
> I'm curious what people here think?

Actually after pondering a bit, he actually does have one valid point.
Although it is hidden below several layers of FUD and nonsense.

When using jack as an interface, the app always _has to meet the rt
contraints_ even if not interested in low latency.

Examples are media players, etc.. 0.5 secs delay don't count as long as audio
and video stay in sync.

So to make jack a little more complete and and to speed up the vanishing of
other sound servers it would be cool to have a possibility of requesting
_larger_ buffers than whatever jack is running at.

This would of course involve extra buffering and _always_ at least one period
of extra delay (kinda like the Mac OS X scheme).

Of course this functionality should be totally optional. If an app wants to
use the direct no-additional-buffering-way it should be free to do so..

What do you think? Is there some concensus that such functionality has a place
in libjack?

And how would it have to look from an API point of view..

Regards,
Flo

P.S.: and while this might be pretty straightforward for audio only jack_midi
would need soe extra work of changing the timecode stamps to correspond to
values in the now larger buffer..

-- 
Palimm Palimm!
http://tapas.affenbande.org