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

Florian Schmidt mista.tapas at gmx.net
Sun Jan 21 14:20:06 EST 2007


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



More information about the Linux-audio-user mailing list