Subject: Re: [linux-audio-dev] Jack and block-based algorithms (was: Reborn)
From: Anders Torger (torger_AT_ludd.luth.se)
Date: Wed Aug 14 2002 - 16:13:12 EEST
On Wednesday 14 August 2002 14.21, you wrote:
> >If I understand Paul Davis' arguments correctly, the main motivation
> >for the Jack design instead of the read/write approach is improved
> >latency.
>
> well, its not really that by itself. r/w-designs can do just as
> well. the real goal is sample synchronous execution *with* low
> latency. if you allow apps to use their own read/write sizes, you
> can't support low latency efficiently, if at all, and even if you
> manage to do so, the different streams can drift in and out of
> sync. this is a natural consequence to using a "push" model ("i'm the
> client, and i'll work when and for as long as i choose") as opposed
> to a "pull" model ("hey client: do this much work right now").
How does the pull model work with block-based algorithms that cannot
provide any output until it has read a block on the input, and thus
inherently has a lower bound on delay?
I'm considering a redesign of I/O handling in BruteFIR to add Jack
support (I/O is currently select()-based), but since it is processes in
blocks, perhaps it is not feasible?
/Anders Torger
This archive was generated by hypermail 2b28 : Wed Aug 14 2002 - 16:14:47 EEST