> Besides I see around the LADSPA API for sound processing but nothing si >milar >for input / output.
there are good reasons for that. > However, what about writing an advanced API for I/O plugins, completely >detached from other programs ( as Xmms ), potentially multiplatform, to suit >the needs of the big part of audio programs? I mean, a plugin written for a there are fundamentally different approaches to handling i/o when it involves hardware. one of them is based on the traditional unix read/write model, the other is based on a callback/interrupt model. its not easy to reconcile these models. in fact, its basically impossible without adding lots of buffering and thus killing latency performance. portaudio *does* support ALSA, but only in CVS. thats as close as you will get to a "standard". ALSA and OSS both provide (or maybe i should say, tend to result in the use of) the read/write model. JACK, CoreAudio, ASIO/EASI/GDIF and PortAudio all require the callback/interrupt model (more or less, anyway). choosing between these two models makes a phenomenal difference to the design of your overall application. its not a choice to be taken lightly, and you can't move back and forth between the two models with ease. now, take a look at the list of apps that support JACK (http://jackit.sf.net/apps). then consider that JACK supports ALSA and OSS on Linux and CoreAudio on OS X, and ask yourself "do you feel lucky?" :))) >certain API ( i.e. ALSA, OSS, Jack, OsX etc... ) will be usable for all other >applications with all advantages of a plugin architecture and standard >code... Input plugins are important too: I see lot of apps rewriting >continuosly Ogg, Mp3 or Wav support in any kind of flavour, but not always >reusable code. About writing it once for all? for audio file I/O, libsndfile takes care of that rather nicely, thank you, and there are an ever growing number of programs that use it. its even gaining popularity in the non-linux world. its hard to see any reason to even think about a different API. --p
