Dan Muresan wrote: > >> > I never much liked the VIO layer. It was only ever added because > >> > a large number of people requested it. I think its fragile and > >> > it exposes too much of libsndfile internals to the user. > > There is one remaining issue that I have discovered while writing > jack-file, and which can only be addressed via a VIO layer of some > sort. While reading a FLAC file, the sndfile request size stream looks > like > > 8188, 8188, 8188, 8192 etc (bytes) > > This is with the user continuously requesting 16384 frames. You will > notice that these are uneven block sizes. If I understand correctly > e.g. the stat(2) page, these are inefficient syscalls: > > "The st_blksize field [of a struct stat] gives the "preferred" > blocksize for efficient file system I/O. (Writing to a file in smaller > chunks may cause an inefficient read-modify-rewrite.)" > > Without a VIO layer (or a libsndfile user-space cache), this is not > solvable by the user at higher abstraction layers.
Whaaat? You're kidding me right? I haven't measured it, but my educated guess is that if you're reading 16384 frames at a time from a FLAC file on current hardware, then the difference between reading st_blksize sized blocks and non-st_blksize sized blocks will be absolutley swamped, by disk latencies, cache latencies, scheduling latencies and file decoding overhead. You might want to google the term "premature optimisation". Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
