linuxaudio.org

Dan Muresan wrote:
> >> > I never much liked the VIO layer. It was only ever added because

quoted text
> >> > 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

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev