On Sunday 21 January 2007 22:21, Esben Stien wrote:
> Florian Schmidt <mista.tapas@email-addr-hidden> 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.orgReceived on Mon Jan 22 00:15:03 2007
This archive was generated by hypermail 2.1.8 : Mon Jan 22 2007 - 00:15:03 EET