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
