Subject: Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)
From: Josh Haberman (joshua@haberman.com)
Date: Tue Feb 04 2003 - 22:47:44 EET
On Tue, 2003-02-04 at 06:03, Paul Davis wrote:
> >Despite that I strongly think that an audio server that not permit in
> >native way the traditional approach (what you call blocking approach)
> >will never achieve the driving role we'd need.
>
> if linux developers continue to work with this traditional model, then
> yes, i think you are right and its a deep problem.
>
> but i see a brighter future because i think that slowly more and more
> developers will choose to adopt the same models they would be required
> to use on windows or macos. this will happen, even if its just because
> the developers will be coming from windows/macos :)
Right now the only ways to choose a callback model in Linux audio
applications are:
* use JACK. Using JACK directly only makes sense for:
1. applications whose only possible use in in a JACK graph (jackrack)
2. applications whose target audience is only people who are so into
RT audio that they're willing to obtain JACK and tweak latency
settings
* write a custom audio thread for ALSA or OSS. This takes a lot of
work and time to get right. I don't know of any applications that
actually do this.
* use PortAudio.
My point is that given the status quo, I don't think we will see a move
to callback-based design. OSS and ALSA are perceived as most native and
most ubiquitous, and these most naturally lend themselves to the
blocking model.
I'm not quite ready to toot my PortAudio horn yet, only because v19 is
not yet ready. Here's what I will say now: I think PortAudio has the
potential to be the unifying force in the fragmented Linux audio world.
Imagine being able to write to an API as simple and well-designed as
this: <http://www.portaudio.com/docs/v19-doxydocs/portaudio_8h.html>
Now imagine that linking against this library will give you access to
OSS, ALSA, JACK, and whatever other APIs come along *all in a single
build*. Imagine getting the same performance as if you had written to
these APIs directly. And imagine having your audio i/o be portable to
Windows and Mac with just a recompile.
This is becoming a reality. I have spent the last week rewriting
Audacity's audio i/o to use PortAudio v19 and simultaneously improving
my PortAudio ALSA implementation to be good enough to support it. The
results have been satisfying.
I foresee resistance from people who perceive portability APIs as a
compromise, as having poor performance. This is simply not the case.
No one would accuse JACK of having poor performance, though it works by
wrapping other APIs. The truth is that the combination of a
well-designed API and careful implementation can yield wrapper APIs that
perform just as well as programming directly to the underlying API.
A great deal of thought has gone into the PortAudio API, you can read a
record of the proposals that went into v19 at
<http://www.portaudio.com/docs/proposals/index.html>
I am interested to hear responses to this. Once PortAudio v19 is
released, would you all as application authors be willing to adopt it in
your programs? If so, why not? In my opinion, the only group of
applications that would not benefit from using PortAudio are those that
are so closely tied to JACK that they don't make sense outside of a JACK
graph.
Regards, Josh Haberman
This archive was generated by hypermail 2b28 : Tue Feb 04 2003 - 22:51:51 EET