Still a long way to go [LWN.net]

Still a long way to go

Posted Aug 3, 2007 8:31 UTC (Fri) by chel (guest, #11544)
Parent article: An Introduction to Linux Audio (O'Reilly)

IMHO the many standards for sound API's (ALSA, OSS, JACK, ARTS, ESD, etc.) still are a problem. A mature system should have a single API that is usable for all applications (and is used by all applications) At the moment, simultanious audio from different applications and in sync with eachother or video, still is a problem.

(Log in to post comments)

Still a long way to go

Posted Aug 3, 2007 13:52 UTC (Fri) by beoba (guest, #16942) [Link]

I'm thinking/hoping that over time a common de-facto standard will emerge. For example, two of those APIs you mentioned (aRts, ESD) are on their way out.

Maybe something at the level of GStreamer or SDL will become the standard, since they aren't as dependant on what OS you're using. Or at least that's the impression I've been getting from their marketing.

Still a long way to go

Posted Aug 3, 2007 18:36 UTC (Fri) by oak (subscriber, #2786) [Link]

Strange that nobody mentioned PulseAudio:
http://www.pulseaudio.org/wiki/FAQ

It's supposed to soon replace OSS and ESD (as API & server) while still
providing API compatible wrapper libraries for older code depending on
those and to offer nicer API on top of ALSA. I.e. it aims to be the
standard linux sound server. It's not intended to replace Phonon,
Gstreamer or JACK, they are intended for different purposes.

Still a long way to go

Posted Aug 3, 2007 20:11 UTC (Fri) by drag (subscriber, #31333) [Link]

Yep. Pulseaudio kicks-ass.

For example it supports zeroconf stuff, Avahi and that sort of thing. It can also be configured to follow network'd X. So that you have network transparent audio and video for X terminals (full duplex for things like VoIP...). It's a drop-in replacement for ESD. And there are plugins for Alsa so normal alsa-using applications can use it automaticly.

Alsa --- low level audio API

OpenAL --- cross-platform gaming audio api. originally developed for port games to Linux by Loki it is now supported by Creative, who is trying to use it as a gaming audio API for Microsoft Vista after Microsoft destroyed the ability to use hardware acceleration for 3D audio in Direct-whatever. (and yes, of course creative is being dicks about it and keeping the hardware acceleration stuff closed). Suppose to be to audio what OpenGL is for graphics.

SDL --- cross-platform 2-d, 3-d, controller I/O, and audio api. Generally for games. Linux, OS X, Windows, and so on. OpenAL was traditionally more sophisticated with dealing with surround sound stuff, but I think SDL has caught up. Nowadays I expect that Linux games should use SDL for audio and controller and use SDL or OpenGL for graphics, depending on how much control the developer needs.

Gstreamer --- used to _build_ applications. Think of it as a collection of building blocks.

Jack --- used for combining and routing PCM audio and Midi between multiple applications for audio work. Designed specificly for low-latency it is good for realtime audio editing and such.

LADSPA --- used for creating audio plugins for audio work for use in other applications

OSS -- now widely considered depreciated in Linux (people debate that) it's a standard audio interface for Unix-like systems.

Esd -- now depreciated in Linux it's designed to solve networking audio and the classic lack of software mixing support (since effectively solved by default use of dmix in alsa, except when you throw OSS or Artsd into the mix) in Gnome stuff.

Pulseaudio --- provide desktop audio for Linux. Drop in replacement for Esd, solves it's perfomance and quality issues. Allows for network transparent audio. Used to be called polyaudio

libao --- Xiph.org's cross platform audio library. Used in simple applications such as mpg321

Arts --- designed to create a standard api for sophisticated video and audio in KDE it's was mainly used to solve the lack of support in Linux for software mixing for non-hardware mixing sound cards. Mostly depreciated, gone in KDE4.

Xine --- a nice application used for media playback. Other applications took advantage of it's functionality for their own use.

Phonon --- simple API for audio for use in KDE4 applications. Designed to abstract away low-level api issues.

That's what I can think of right now.

PulseAudio

Posted Aug 4, 2007 9:50 UTC (Sat) by wolfgang.oertl (subscriber, #7418) [Link]

I have looked at PulseAudio recently, did almost all of the "perfect setup" described on the pulseaudio.org wiki. Works nicely, but it has a high CPU overhead on my system - while doing nothing (well, a few % of CPU) but even more when playing back audio.

This inefficiency needs to be fixed before it can be a standard, especially in the light of all the power saving efforts currently under way.

PulseAudio

Posted Aug 4, 2007 20:46 UTC (Sat) by drag (subscriber, #31333) [Link]

It's configurable how much cpu time you want to allow it to use.

The lower the latency and the tighter your audio requirements the more cpu time your going to use. If you loosen things up it will use much less cpu time.

From the /usr/share/doc/pulseaudio/README.Debian on my system:

> PLEASE NOTE: PulseAudio's default configuration uses high quality sample rate conversion that may be overly CPU intensive. If PulseAudio's CPU usage is unacceptable on your hardware, please change the resample-method option in /etc/pulse/daemon.conf to either src-linear or trivial. See daemon.conf for more details.

Still a long way to go

Posted Aug 5, 2007 6:23 UTC (Sun) by njs (subscriber, #40338) [Link]

> Alsa --- low level audio API

The problem with Alsa is that it is a bit confused about what level API it is supposed to be -- on the one hand there are the kernel drivers, which export a very low level interface to userspace, and then there is libasound. In practice, libasound is the only way to use the low level kernel drivers (IIRC they even get in trouble with the kernel developers because the kernel<->libasound interface is not even stable), and libasound adds all sorts of strange non-low-level stuff. It has plugins, you can route audio in weird directions, "dmix" actually uses sysv ipc to perform software mixing between multiple libasound users, etc. etc. All this in the lowest-level stable interface available.

My vague and uninformed impression is that alsa should back off to focus strictly on exposing the hardware, then pulseaudio and jack should provide the fancy stuff on top of that, and apps should target whichever is appropriate for the app in question. (Or pulseaudio and jack could hybridize to create the Ultimate User-Space Sound System, that'd be cool too.)

Still a long way to go

Posted Aug 7, 2007 20:40 UTC (Tue) by nix (subscriber, #2304) [Link]

libsydney: another does-everything API with a silly name which PulseAudio
will eventually transition to, only I'm not sure it's actually even alpha
yet.

Still a long way to go

Posted Aug 3, 2007 21:04 UTC (Fri) by jrigg (subscriber, #30848) [Link]

Given the conflicting requirements of realtime audio recording in a professional studio versus desktop sound, I think it would be a little unrealistic to expect one API to handle everything. I make a significant part of my living from sound recording using Linux audio software. It works extremely well for this. I just hope that any changes designed to make things easier for the average user don't render it useless for professional purposes. IMO the two types of application are better kept separate.

Still a long way to go

Posted Aug 3, 2007 23:14 UTC (Fri) by johnkarp (subscriber, #39285) [Link]

What you say makes perfect sense to me.

Apparently, though, Apple uses a single API for both applications,
CoreAudio. I'd be curious to see how that is implimented, particularly how
they deal with latency.

Still a long way to go

Posted Aug 4, 2007 4:06 UTC (Sat) by drag (subscriber, #31333) [Link]

It's suppose to be very good in terms of latency. People claim sub-10msec is reliable, but people claim all sorts of stuff about OS X that they shouldn't.

Still a long way to go

Posted Aug 4, 2007 9:17 UTC (Sat) by chel (guest, #11544) [Link]

I don't think the requirements are conflicting. At the moment mixed use of e.g. Flash, Mplayer, XMMS and VLC is a big problem. Just read the HOWTO pages and you will see it is unreachable without the thorough knowledge of the many sound systems available. For my professional audio (http://www.vangennip.com) I still use the Samplitude application that came with the soundcard I bought in the previous century. For the moment I don't have working tools in Linux to check if my audio and video really are in sync. Of the list posted by Drag, 90% or more should be removed completely, the remaining parts should be fixed to get a real working sound system. BTW, there is a major difference between realtime and fast. The major requirement of realtime is "predictable timing" and that won't hurt any application.