11 May
2004
11 May
'04
7:44 p.m.
Hi all,
the reason of this mail is searching for opinions about an API for input /
output plugins.
Besides I see around the LADSPA API for sound processing but nothing similar
for input / output.
From some months I'm playing around with audio I/O libraries: I met too much
libraries but no one really complete satisfacting my needs( thinking to
latency and other advanced issues having on djing programs as an example).
Not talking about driver complete support: PortAudio does not support ALSA,
libao does not support Win,MacOsX and so on...
Playing with plugins about some program I had another problem: I played with
Alsaplayer ( very nice and powerful program! ) trying to reuse its plugins. I
found although, that using them means including ( with hardcode ) lot of the
Alsaplayer code. I played with Xmms too: this time the work is easier and
there are all sort of plugins but mostly are thinked for merely playback
withouth latency control... ;-(
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
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?
I wanna know: there are people interested in this? My discussion is out of
any order, not clever, low level? There is disadvatages on this idea?
Suggestions?
If there is a reason: Plugin API For Input Output ( PAFAIO ) sounds well???
Hoping in some answers.... Cheers,
--
J_Zar
Gianluca Romanin
----------------
see you at OpenJay.Org
11 May
11 May
8:08 p.m.
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
8:38 p.m.
On Tue, May 11, 2004 at 06:01:04PM -0400, Paul Davis wrote:
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.
...
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.
True, but OTOH it's quite easy to convert ALSA to a 'callback' model,
and that's in fact what all apps that support both ALSA and JACK (and
of course also JACK itself) are doing. Basically all you need to do
(besides the normal ALSA incantations) is to create a thread.
But I agree 100% that there is no need for an I/O plugin standard.
With JACK and ALSA available, you can more or less forget about all
the rest.
--
FA
13 May
13 May
6:58 p.m.
Alle 00:01, mercoledì 12 maggio 2004, Paul Davis ha scritto:
This is a good reason... agree
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
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).
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 
7:52 p.m.
On Thu, May 13, 2004 at 10:51:53PM +0200, J_Zar wrote:
Actually, Conrad, the author of sweep, and Erik were recently talking
about efforts in the works to add ogg-vorbis and later ogg-flac support
to libsndfile via Conrad's libfishsound. See this thread:
http://eca.cx/lad/2004/05/0072.html
-Eric Rz.
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.
...
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.
15 May
15 May
2 p.m.
Alle 23:39, giovedì 13 maggio 2004, Eric Dantan Rzewnicki ha scritto:
On Thu, May 13, 2004 at 10:51:53PM +0200, J_Zar wrote:
Actually, Conrad, the author of sweep, and Erik were recently talking
about efforts in the works to add ogg-vorbis and later ogg-flac support
to libsndfile via Conrad's libfishsound. See this thread:
http://eca.cx/lad/2004/05/0072.html
-Eric Rz.
Thank you Eric... Very nice news!!!!
Cheers,
--
J_Zar
Gianluca Romanin
----------------
see you at OpenJay.Org
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.
...
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.
7708
days inactive
7712
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Eric Dantan Rzewnicki -
Fons Adriaensen -
J_Zar -
Paul Davis