Re: [LAD] [LAU] cancelling I/O with libsndfile

> 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jun 14 16:15:07 2011