<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 30, 2013 at 5:57 PM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org" target="_blank">fons@linuxaudio.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">These questions are really directed to Paul Davis (as the<br>
main Ardour dev), Erik de Castro Lopo (libsndfile author),<br>
and anyone with experience in this field.<br>
<br>
Imagine a real-time audio processing app reading (or writing)<br>
lots of audio files, possibly evaluating a complex timeline<br>
consisting of many separte pieces. To make things work some<br>
(or a lot of) buffering and lookahead will be necessary.<br>
<br>
There are at least three distinct places where this can be<br>
done:<br>
<br>
1. the file system(s) and kernel<br>
2. any library used to acess audio files,<br>
3. the application itself.<br>
<br>
Of these, only (1) will be aware of any hardware related<br>
issues, and only (3) will be aware of what is expected to<br>
happen in the (near) future. (2) sits somewhere between<br>
the two.<br>
<br>
In view of this, what is currently the best way for an<br>
app to read/write audio files, the basic read() and write()<br>
calls, or the stdio interface ?<br>
<br>
More specifically, if one would write a library to access<br>
a particular audio file format (not supported, or only<br>
partially by e.g. libsndfile), how 'smart' in terms of<br>
buffering, lookahead etc. should that library be, or not<br>
try to be, in order to perform well with apps like e.g.<br>
Ardour ? What form would the preferred API take ?<br></blockquote><div><br></div><div>(1) libsndfile has a sort-of-plugin architecture that makes it relatively easy to add support for new formats<br></div><div>(2) it matters quite a lot whether you plan read-only, write-only or read-write access. but not that much.<br>
</div><div>(3) my sense is that as long as you buffer adequately in the application, and do not use a *stupid* filesystem,<br></div><div>       most modern kernels + filesystems will perform well enough without playing any special games. ie.<br>
</div><div>       just seek, read/write, done.<br></div><div>(4) if you want to optimize performance to the maximum possible, then you need a lot more about<br></div><div>       filesystem behaviour, such as block allocation strategy. i don't believe that this is particular useful<br>
</div><div>       at this point in time, but i may be underestimating its benefits.<br></div><div>(5) i have (in the past) seen the kernel delay disk i/o by several seconds<br></div><div><br></div><div>ardour uses libsndfile as-is, of course (though tries coreaudio's APIs if libsndfile doesn't work, on OS X, since that provides access to additional formats like mp3). <br>
</div><div> <br></div></div></div></div>