| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Still a long way to go
Still a long way to go
Posted Aug 3, 2007 13:52 UTC (Fri) by beoba (guest, #16942)In reply to: Still a long way to go by chel
Parent article: An Introduction to Linux Audio (O'Reilly)
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.
(Log in to post comments)
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 PulseAudiowill eventually transition to, only I'm not sure it's actually even alpha
yet.