Re: [LAD] A question about audio file interfaces

From: Paul Davis <paul@email-addr-hidden>
Date: Sun Dec 01 2013 - 01:07:31 EET

On Sat, Nov 30, 2013 at 5:57 PM, Fons Adriaensen <fons@email-addr-hiddenwrote:

> These questions are really directed to Paul Davis (as the
> main Ardour dev), Erik de Castro Lopo (libsndfile author),
> and anyone with experience in this field.
>
> Imagine a real-time audio processing app reading (or writing)
> lots of audio files, possibly evaluating a complex timeline
> consisting of many separte pieces. To make things work some
> (or a lot of) buffering and lookahead will be necessary.
>
> 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 ?
>

(1) libsndfile has a sort-of-plugin architecture that makes it relatively
easy to add support for new formats
(2) it matters quite a lot whether you plan read-only, write-only or
read-write access. but not that much.
(3) my sense is that as long as you buffer adequately in the application,
and do not use a *stupid* filesystem,
       most modern kernels + filesystems will perform well enough without
playing any special games. ie.
       just seek, read/write, done.
(4) if you want to optimize performance to the maximum possible, then you
need a lot more about
       filesystem behaviour, such as block allocation strategy. i don't
believe that this is particular useful
       at this point in time, but i may be underestimating its benefits.
(5) i have (in the past) seen the kernel delay disk i/o by several seconds

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).

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Dec 1 04:15:03 2013

This archive was generated by hypermail 2.1.8 : Sun Dec 01 2013 - 04:15:03 EET