Audio Input-Output Library 0.2.0 review

Audio Input-Output Library (libaio) is meant to solve the problem of differing digital audio platforms once and for all. JACK is u

License: LGPL (GNU Lesser General Public License) File size: 0K Developer: Hod McWuff

0

Audio Input-Output Library (libaio) is meant to solve the problem of differing digital audio platforms once and for all.

JACK is unnecessarily complex for most applications, and while libao's support for file output is cool, it limits what the API can do and is therefore inadequate for any kind of real time application.

libaio provides a clean application interface and a simple compile-time driver switching decision, yielding a lightweight way to use the local sound hardware without having to care what it is.

Libaio's first sparkle was when I, Hod McWuff (alias, of course), found myself trying to debug ALSA implementations for libao and madplay, and another audio-related project I'd been working on. That project needed multiplatform audio support of its own, with latency management, which libao lacked.

It also seemed that libao shouldn't have been trying to be both a hardware abstraction *AND* an output abstraction, and also that it seemed more intuitive as an output (live vs file) abstraction.

Enter libaio. All it does is abstract the local sound hardware platform, to present a clean, uniform interface to playing and capturing digital audio, with facilities for basic latency management. It was written from scratch around its developing ALSA driver, from many many reference sources including libao and Robert Leslie's excellent madplay MP3 decoder, and of course the ALSA documentation and examples.

Libaio's distinction comes from its build-time decisionmaking. It only compiles and links the best driver available for the given platform. Therefore, selecting and loading a driver no longer applies; and well it shouldn't, there's never more than one correct choice anyway.

Libaio is not intended to replace libao; rather it is intended to supplement it. The key argument is, why would anyone EVER have more than one running sound platform type on any single machine? Sure, they might have ESD or ARTS, but they more resemble file output than a live device. There's also the OSS emulation in ALSA, but given a good ALSA driver, who'd use OSS?

Then there's the fact that applications have to tell libao what "plugin" to use, and all the drivers in libao have different parameters. That means the application has to know more than it should about what it shouldn't have to see. The app shouldn't have to say more than "give me the local device for playback with *** format" or something to that effect, and start writing.

Finally, plugins for stuff like proprietary file formats, ESD et al, but there shouldn't be any need for more than one of (ALSA|OSS|SUN|WIN32|MACOSX ) on any given distribution. Therefore, binary distribution of a compiled-in driver is possible, even preferred.

It is proposed that all of the hardware drivers in libao, and madplay, and several other places, be reviewed and ported to libaio. Then, they can be removed from those packages in favor of an AIO interface.

Installation:

## building
./configure
make


## installing (as root)
make install