> 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 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
