On Sunday 21 January 2007 22:21, Esben Stien wrote: > Florian Schmidt <mista.tapas@xxxxxxx> writes: > > Is there some concensus that such functionality has a place in > > libjack? > > I don't understand this. Why care about the JACK buffer?. Why not just > buffer a little before?, especially with a media player. Well, in this case the media player has to do all the decoupling from jack, which, while not terribly complicated, does have some pitfalls.. If you simply say: "jack, give me a 0.5 sec buffer" you can get away with quite a bit of non-rt programming, because a 0.5 sec deadline is rather easy to meet (maybe the need to prebuffer in the media player is gone completely). It's about making jack easier to use for application programmers, that do no care for quick response times (a realtime effect processor would care, as would a softsynth, but my media player doesn't). In the world of audio applications there are quite a few usecases where latency is not that much of an issue. Those apps should be able to happily coexist in a jack graph with low latency apps. And as there are quite a few of these apps, the problem should be solved once and not by every app writer again and again.. A blocking interface like in libjackasyn, which partly solves this problem afaict, would be a nice feature, too.. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org
