Lennart Poettering, main programmer of the PulseAudio project, has written a 'Guide Through The Linux Sound API Jungle': "At the Audio MC at the Linux Plumbers Conference one thing became very clear: it is very difficult for programmers to figure out which audio API to use for which purpose and which API not to use when doing audio programming on Linux. So here's my try to guide you through this jungle."
To read all comments associated with this story, please click here.
Member since:2008-07-15
Actually, as soon as commercial apps enter the mix the end user usually does have to deal with it, unless they have one of the few hardware multi-channel cards that ALSA actually supports. Most commercial apps use OSS and believe me, ALSA+OSS+PulseAudio is not a trivial setup to get working, seeing as how ALSA's oss layer is basically worthless--nothing sent through it uses any of ALSA's settings, so it pretty much ignores your pulseaudio setup. Sure, you can use padsp or preload whichever DSP library you need, but that doesn't work in all cases--try that in vmWare workstation and see how far you get, for instance. Try it with audacity, you won't get very far. Perhaps OSS did shoot themselves in the foot in regard to their licensing and slow updates--I'd say that's a given. But why did ALSA have to completely redesign the API? For the longest time, ALSA wasn't stable--remember the days of ALSA 0.4 vs 0.5 vs 0.9? Why are the drivers in many cases immature? Why is there no reliable way to switch the default audio device, something so simple? Why is ALSA's software mixing layer so bad that we needed Pulseaudio in the first place? Why is the OSS emulation layer half-baked even after all this time?
The OSS API is stable, standard, and simple. I agree that the Linux audio system needs to be rebuilt from the ground up. If the kernel DEVs don't want to use OSS, at least implement the API properly. It would increase compatibility and decrease frustration all around. Oh, wait, that would take foresight and organization. I guess I was just dreaming.
Member since:2008-07-15
Member since:2007-06-28
actually, i don't find it difficult to get a decent working setup with ALSA + JACK. i don't use many OSS-only apps at all. and frankly, there are very few commercial apps written for OSS, in the grand scheme of things. if you're going the commercial-software route, linux is (sadly) not the best platform for audio work.
there are many multi-channel cards with support. admittedly, there are still many very popular interfaces with no support in ALSA. FFADO picks up some of the slack for firewire interfaces. but, the lack of proper drivers (ALSA, OSS, and FFADO) is the fault of the hardware developers for refusing to provide specs. and it's not like OSS has oodles of support from manufacturers that ALSA is lacking.
ultimately, it's pretty simple nowadays to get a decent setup going for multi-track recording. RME and m-audio pci interfaces have decent ALSA drivers, and echo makes some great FW (and PCI) interfaces. add a mixing console, jack and ardour, and you've got a quick and easy recording studio.
it's not that we have a perfect situation... but, if you have a workflow that necessitates commercial software and unsupported hardware, linux just isn't what you should be using right now.
all of this is sort of a silly discussion though. in my original post, i was just trying to point out that for most typical (i.e. non-pro) users, the confusion is really artificial and not at all necessary. for mr. average joe with onboard audio, everything usually just works.
edit: forgot to mention pulseaudio. for any of my studio boxes, pulseaudio is not even installed, or necessary. it's really just ALSA + JACK for me.
Edited 2008-09-28 01:12 UTC
Member since:
2007-06-28
this article is pretty nice for developers just getting into linux audio. especially considering the author's affiliation with pulseaudio. i'm glad he's being forthright about pulseaudio's purpose and not trying to make it out to be some magical one-size-fits-all solution, like some people not related to the project seem to believe.
but, from an end-user perspective, most of the confusion is very much blown out of proportion.
if you're a typical linux user, you ARE using ALSA, unless you've gone out of your way to avoid it. ALSA simply provides audio drivers for your soundcard.
if you're using a desktop environment, you probably are running an additional sound daemon so that multiple applications can output audio simulaneously, like a software mixer. if you're on an older gnome distro, this is ESD. on a new gnome distro, it's probably pulseaudio. if you're on an old KDE distro, this is arts. on a KDE4 distro, phonon, i guess.
none of these things are choices a typical user has to make. they're all just small pieces of the pie.
the only time an end-user really should have to make a choice is if they are doing any professional audio work. if they need a low-latency solution with inter-application audio streaming, then it's advisable they read up on JACK.
honestly, that's really all there is to know for MOST end-users.
your hardware talks to ALSA, which talks to your sound server, and add JACK if you need to use professional audio software.
the only truly damning problem is when a distro ships a misconfigured sound setup and the end-user is forced to troubleshoot with no background knowledge. for example, the latest ubuntu release with it's funky pulseaudio setup.
lastly, the OSS situation really depresses me. is it superior to ALSA? maybe it is, maybe it isn't. but, ultimately, they shot themselves in the foot with slow updates and licensing problems. ALSA superceded them because we NEEDED a solution we could count on. they didn't catch up until it was too late. crying that it's not fair isn't going to change the fact that OSS missed their window of opportunity. heck, they *squandered* their lead.