14 Jun
2011
14 Jun
'11
2:55 p.m.
The intermediate one doesn't have that and may
well work against
you. The same problem exists with the system level buffering,
Yes. Well, the worse clash is between the kernel-space vs. the
user-space caching strategy, but indeed you can't do much about it
(unless you go the O_DIRECT way like databases).
is 2 seconds, so that's 8 commands to read 1/4 of
second. You can't
safely start playback again unless you have at least a second or
On transport relocation, I was planning to be un-safe, compromise on
the cache pre-fill percentage and accept the possibility of a few
application-level (not Jack-level) under-runs -- in the interest of
(likely) gapless payback. The cache should catch up gradually,
depending on the streaming-to-playback bandwidth ratio.
But otherwise you are right.
so buffered. No assume you have a new relocate before
that time.
I'm not considering this yet, but I see your point about there always
existing a single un-cancellable request.
If the reads happen on an NFS volume then even if the
cancel would
work on the client side that doesn't imply that the data won't
be transmitted by the server anyway. So nothing would be gained
This depends on whether it's a WAV or a compressed file, and on the
NFS rsize and wsize mount params I guess (or I'm missing something).
Thanks for the analysis.
Best
Dan