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
