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/ _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
