Alle 00:01, mercoled� 12 maggio 2004, Paul Davis ha scritto: > > 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. >
This is a good reason... agree > 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). > I found the PortAudio support for Jack too... nice! I don't know this. This is enough to judge stupid my idea! Thank you Paul. > 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?" :))) > Yes I do ;-D > >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 Well... To be onestly sndfile does not support Ogg and will never support Mp3. These two formats are maybe the 40/50% of the whole audio stuff. Ok but Mad and Vorbifile are enough. Finally I agree: no reason for I/O API. Thank you for the time lost for me! -- �������� � � J_Zar ��������Gianluca Romanin ��������---------------- � � � see you at OpenJay.Org
