> Regardless of whether you choose to measure latency or CPU load > if you vary the st_blksize as specified in the previous email, > you will not be able distinguish between the two values of > st_blksize due to the influence of other factors.
What are you talking about? How can one vary st_blksize or choose a preferred value for it? Are you assuming that I am writing a kernel driver? Why? If you meant the actual request size, then I think that (1) none of us have performed measurements and (2) as I stated, if no measurements have been performed, and if the implementation allows it, standard recommendations should be obeyed. > The behavior of fread() can be dubious for files accessed > via NFS with respect to incomplete reads (ie EAGAIN). The > only solution to this is to use read(). Please detail this somewhat. NFS was one of the use-cases I mentioned in the beginning (and I actively use it). >> else address the issues that arise from breaking the rules (i.e. > > Breaking what rules? K&R C and even CS1 choices (fread / fwrite), unless you have a reason to break them... Not that I would be at that level... > You provide concrete proof that doing block sized reads makes > any positive performance improvement and I'll implement block > sized reads and buffering. You have already said you would accept patches and contributions for this specific issues (a userspace cache) in past e-mails. Are you retracting (or qualifying) the offer? In any case, you already have the VIO layer, which certainly WFM -- my programs work. > Until you can show concrete proof I consider this issue closed. Which issue? I was merely discussing choices. And I was arguing that YOUR VIO code is a GOOD thing. Uh, please don't remove it :) Anyway, I have found sndfile to be an extremely valuable library. -- Dan _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
