>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").
--p
