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
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
On Wednesday 14 August 2002 15.23, you wrote:
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
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
On Wed, Aug 14, 2002 at 03:13:12 +0200, Anders Torger wrote:
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?
It makes it trickier. If the jack period size is giong
On Wednesday 14 August 2002 15.51, you wrote:
On Wed, Aug 14, 2002 at 03:13:12 +0200, Anders Torger wrote:
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?
It
On Wednesday 14 August 2002 15.51, you wrote:
On Wed, Aug 14, 2002 at 03:13:12 +0200, Anders Torger wrote:
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?
It
