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

From: Erik de Castro Lopo <mle+la@email-addr-hidden-nerd.com>
Date: Tue Jul 05 2011 - 02:30:35 EEST

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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jul 5 04:15:01 2011

This archive was generated by hypermail 2.1.8 : Tue Jul 05 2011 - 04:15:01 EEST