1 Dec
2013
1 Dec
'13
2:43 a.m.
Fons Adriaensen wrote:
There are at least three distinct places where this
can be
done:
1. the file system(s) and kernel
2. any library used to acess audio files,
3. the application itself.
Of these, only (1) will be aware of any hardware related
issues, and only (3) will be aware of what is expected to
happen in the (near) future. (2) sits somewhere between
the two.
In view of this, what is currently the best way for an
app to read/write audio files, the basic read() and write()
calls, or the stdio interface ?
More specifically, if one would write a library to access
a particular audio file format (not supported, or only
partially by e.g. libsndfile), how 'smart' in terms of
buffering, lookahead etc. should that library be, or not
try to be, in order to perform well with apps like e.g.
Ardour ? What form would the preferred API take ?
In case you hadn't realised it, file formats are important.
Basically, if libsndfile needs to do any audio data format
conversion (eg int -> float or vice versa, endian swapping
etc) then it reads data from disk into an internal buffer
and then converts the data from the internal buffer to the
buffer you provided. Since the internal buffer is only about
16k, if you read large chunks, the conversion is done in a
loop with lots of smaller reads.
However, if for instance you are reading a file with 32 bit
float data with host endian-ness into a 32 bit float buffer,
then no conversion needs to take place and libsndfile simply
passes your buffer to the read syscall.
Obviously, it you care for performance, the second one is
vastly preferable and gives you a reasonable amount of control
over bufferring.
Hope this helps.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/