[linux-audio-dev] newest audio server for Linux (yep, yet another)

[David Olofson]

On Tuesday 04 February 2003 21.47, Josh Haberman wrote:
[...]
> 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.

I've never really thought of any other way to use ALSA or OSS... 
Audiality does it, although the current (unreleased) version adds an 
"interesting" twist with the new I/O layer... It allows interfacing 
with both callback APIs and read()/write() APIs, while still having 
only one master engine callback, and block oriented read()/write() 
write callbacks for "drivers". Sort of weird. Might have done 
something stupid. Or not. Either way, it's better than the old hack! 
:-)

Anyway, am I missing the point?


> * use PortAudio.

Well, there's one more, that doesn't do input but still: SDL.


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

That sounds *really* great, of course. It's just what I need for 
Audiality, so it's obviously something I'll add in a not too distant 
future.

Would be cool if even more platforms were supported, but OTOH, in the 
case of Audiality, that's mostly for games that use it as a sound 
engine - and SDL works fine for that.

(The only game to use it so far, my XKobo port "Kobo Deluxe", runs on 
some 10 platforms. I don't know for sure if it does audio on the 
PDA(s?) and 68k Amiga, but AFAIK, it does on Linux, Win32, Mac OS X, 
FreeBSD, Solaris/SPARC, Solaris/x86, BeOS and probably some others I 
can't remember right now.)


[...]
> I foresee resistance from people who perceive portability APIs as a
> compromise, as having poor performance.

One would think people should know better these days... Any 
performance issues with OpenGL? ;-)


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

I would say SDL (the graphics stuff) is a perfect demonstration of 
this. The API is as simple as it gets, it runs on *loads* of 
different platforms, and it's just about as fast as it gets on most 
of them. Still improvements to be made (supporting some more h/w 
acceleration APIs, for example), but I think my glSDL - a 
proof-of-concept implementation of the 2D blitting API on top of 
OpenGL - demonstrates that the API fits pretty much anything. (OpenGL 
is *very* far from a raw framebuffer...)


> 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?

I would, definitely, since extreme portability is a major design goal 
for most of my projects. Anything that works well on more than one 
platform is of interest, basically. (As is anything that works 
*really* well on Linux, of course, since that's where I'll be running 
my software most of the time. :-)


> If so, why not?

Indeed.


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

That's not Audiality - which doesn't even have JACK support yet. :-/

OTOH, I'll need a nice replacement for the ALSA sequencer, if the 
thing is to be usable for anything but music and SFX playback on 
other platforms. Currently, the most "portable" control API I have is 
OSS rawmidi... *heh*

I've considered hacking native Win32 MIDI support (the "new" MIDI API 
with timestamps), but... let's just say I don't care enough for 
Windows to spend time on that. (I'm in the middle of the final step 
away from using Windows for music at all. Just need to hack 
Rosegarden a little, and it'll fit the bill, I think...)


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---