Every operating system has different sound systems and APIs to access the sound card, so that no low-level coding is required to use the sound device. Programmers have many different choices concerning which system to use, especially under Linux — and maybe that’s the problem. This article illustrates free sound architectures on Linux, as well as the different interfaces a programmer can use.
An introduction to Linux sound systems and APIs
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
A good article that introduces the basics of sound programming in Linux using the various APIs available by showing various example code snippets. I do agree with the author though, the ALSA function names and parameters do look ‘long’, but still not quite as bad as Win32 API function calls.
Looking forward to the 2nd installment which deals with portable sound programming.
How could they not mention GStreamer?
Even ignoring some of the amazingly powerful stuff you can do with it, gstreamer has sinks for arts, alsa, oss, and probably more that I don’t know about (like network sinks, etc…)
It is cross platform across all the *NIX’s and is getting ported to windows.
The size of the library on my FC2 system, without development headers, debug info, and any of the extra plugins, is 1.9MB
It also has a number of language bindings (http://gstreamer.freedesktop.org/bindings/)
And all of this without mentioning some of the amazing things it can do with some of the most interesting pipelines.
You mean that it’s not dead yet? Oh wait, it has never been really alive
Only sort of…
Why has it still not matured? Not enough outsiders interested in it? Also, doesn’t gstreamer do a lot more than just being a sound system?
Nice, I was hoping to see an article like
this since the info on sound(and much else) in
the LDP(linux documentation project) is hopelessly
stuck in kernel 2.2 land.
I
As a user who uses an underpowered P II computer
with 128Megs of ram to run Madman(a jukebox) and other
linux sound goodies..I frequently get the message
( “sound server died, sound will continue to /dev/null”)
I find that switching the server(in KDE control panel)
to to OSS threaded or another sometimes fixes the problem.
Or better yet, use Xmms and less cpu..the main thing
an average user wants is of course to be able to hear
two sound simutaneously and for the most part
this works..
On my more powerful P4 computer with the i810 card
there are still some problems(kernel 2.4, kde3.2)
I hope they fix the problem with the i810 cards..they
often blocked sound from the 2nd app if another app
was using sound. This under ALSA.
Sound has always been a sticking point for me in Linux. ALSA was a PITA to set up in Gentoo (I think I had to recompile things 5 times before it started working) and it wasn’t properly set up in some of the more user-friendly distros I tried. Later on, aRTs kept using 100# CPU and then dying on me… sound’s really been my only beef with linux. Once all this was nominally working, I had to laugh when, after listening to an MP3 in XMMS, I heard a constant stream of GAIM message alerts. This is an example of a place where linux needs a single, open, pluggable standard architecture.
So, do these technologies support the more advanced features found on some new cards? Like Dolby Surround or 14-whatever channels and subwoofers?
Is something like Dolby even possible in GNU/Linux? I can imagine problems wih licencing for those technologies.=
Being one of the principals behind Open Sound System, I can tell you that this article has been written without doing any research.
OSS the API is stable and is very advanced even when it was originally written in 1993. Everything one can do with ALSA can also be done on OSS drivers. OSS drivers (gpl’ed and commercial) are all full duplex and the ALSA guys keep raging on FULL duplex features of ALSA – only one OSS driver was intially not full duplex (SB16) that was eventually made full duplex.
OSS v4.0 is due out sometime this year and we will be adding new features while maintaining 100% backward compatibility for apps written as early as 1994.
Any app you want to run on ALSA will also run on OSS (via Jack for OSS). The author has show some examples of ALSA programming….exactly how is this advanced compared to OSS?
People learn one new term “deprecated” and that’s all everybody keep writing in every single article. Little does anybody know that without OSS API emulation, ALSA would ever have been allowed into the kernel by Linus.
Its funny that XMMS (another of 4Front’s products that is GPL’ed and relies on sales of commercial OSS drivers for paying developers salaries) works better with OSS API emulation on ALSA drivers than the native ALSA api support.
This support for XMMS was not written by us but by one of the ALSA people. So tells you that even the ALSA developers
have problems writing apps to their own API.
OSS has more advanced features than ALSA – why not download the latest OSS drivers and see for yourself. It’s more user friendly and easier than ever to isntall it. Now there’s no reason not to run OSS – because its free (as in free beer)
for noncommercial/home use. It’s 20 dollars if you need support and we’re so sure you’ll never need it. If you’ve been wasting hours trying to configure ALSA, spend 10 minutes downloading and installing OSS and get productive instantly.
People are still widely deploying OSS API drivers and apps – just look at the embedded space and if OSS as an API was dead, how come Skype comes out with a brand new app that’s OSS API based. All the major games – Unreal/Doom/Quake still use OSS. RealPlayer 10 still uses OSS. OSS isn’t dead yet (gosh I sound like Monty Python’s Holy Grail….I’m not dead yet….I’m feeling better, I think I’ll go for a walk….)
The advantage of OSS is write one compile anywhere – and in case of FreeBSD/UnixWare/LynxOS and Solaris (Janus or Lxrun) you’ll be able to run Linux binaries and they just work with OSS drivers on the native platforms. So people on FreeBSD can still use Linux binaries for Flash/Real/Skype and use either native OSS/Free drivers or use our commercial ones and get audio without any loss in functionality. This is good because commercial developers have no interest to have a FreeBSD binary or support other obscure UNIX versions.
ALSA’s call back routine is just pure madness. Just because Apple does an event driven audio API that works well with MacOSX, doesn’t mean that it’s a safe model in Linux. Even driver drivers are just asking for trouble. Try doing that in real time environments.
As for the ALSA API itself, we humbly beg to differ. ALSA is not advanced because if it were, we would not be able to create an ALSA compatibility module that just maps ALSA high level calls into OSS low level calls. ALSA is a moving target and thus cannot and should not be relied to develop anything natively.
I’d fully recommend people to use Jack if they are averse to writing to OSS (“pure unix”) APIs.
I invite you to download and try out the OSS drivers even on Linux – check out the new equalizers, fidelity enhance, 3D surround – everything you normally get only on Windows (eg:
SRS WoW or QSound iQFx or Spatializer StreamFX).
Just wanted to let people know about FUD and that just because you pay for drivers, doesn’t make us evil. If you want free drivers, tell Redhat/CreativeLabs/etc to pony up for our salaries and we’ll gladly give you free stuff.
As for 4Front, we are just not a UNIX driver or XMMS company any longer, we also have products in Windows (check out the equalizer stuff in Winamp – see the credits if you doubt us) as well as VSTs for MacOS.
best regards
Dev Mazumdar
President
http://www.opensound.com
Never been alive? In terms of audio support it is very much mature and pretty well used. Expect when version 1.0 gets released (which will take a while, since when that is released the API needs to stay stable for a while) for it to get used much more in gnome. (currently it is only so-so used)
Also, there is a very strong possibility that it will be used in KDE 4.0. If that does happen then gstreamer will be the defacto audio/video framework to ues that can garentee everything from cross platform support, to network transperency.
If you think that gstreamer isn’t alive, then you havn’t been paying attention.
Note: I am not a gstreamer developer in any way.
I hear ya. I don’t like ALSA either, too many problems as a user (I had written a long explanation on this, but the freaking Safari lost the text while I was typing fast on my powerbook and I can’t undo the operation). However, I am sure that OSS has equally as many problems, otherwise Linus wouldn’t put ALSA into the kernel. All in all, I am not happy with sound on Linux: with either OSS or ALSA. Too many little and big problems (that I won’t retype).
The reason Linus put in ALSA was that the OSS drivers were
losing “consistency” because different people had written OSS drivers – ALSA is basically the work of 2 developers (may be 3) but let’s look at ALSA 5 years down the road when there are too many cooks. Linus put in ALSA after political pressure from ALSA guys and the fact that Alan Cox was leaving to pursue his MBA.
As you can see this article completely glosses over OSS by stating that it’s “deprecated”. When you keep hearing the same word and term bandied by several people who simply back ALSA because it’s covered by GPL rather than OSS that’s BSD – you have to ask yourself if they are all drinking the same coolaid or are they being objective.
We’re trying to figure out why is OSS being singled out as being evil. People are happily giving CodeWeavers and VmWare or other commercial apps rave reviews while these apps compete with their open source/GPL cousins like Wine or Bochs.
Try OSS sometime….especially if you’re into MP3s or Games or DVDs.
Best regards
Dev Mazumdar
Ok I remember trying oss on aan ols knoppix a couple
of years back..It played mp3s fine..but when I
enabled sound on my chess program (just a click noise
when a piece moved) the result was NOISE whenever
the 2 apps were working at once..Not acceptable.
I noticed a threaded oss server on knoppix,
would this fix the problem? I would love top know
more about this issue..has oss improved to take
care of this issue?
> but when I enabled sound on my chess program (just a click noise when a piece moved) the result was NOISE whenever
the 2 apps were working at once..Not acceptable.
Most likely a bug with artsd (isn’t Knoppix KDE based?).
Typically if you use artsd with OSS, you should have no problems with multiple sounds as long as apps support OSS API.
If you had noise without Artsd server, your chess game was badly programmed.
I have not looked at difference between threaded OSS and non-threaded OSS. But you can try setting the sampling rate to 48Khz and see if that solves the problem. What soundcard did you have the problem with?
best regards
Dev Mazumdar
It would be nice to hear from the ALSA devs (Jaroslav?). I’ve heard it mentioned before over and over that ALSA was much better (in terms of features it allowed apps to use as well as driver development), and have always taken the author’s word on it. This is the first time I’ve heard anyone from the OSS camp actually say something (not that I’m saying they haven’t in some publications. I just honestly haven’t read any)
“ALSA’s call back routine is just pure madness. Just because Apple does an event driven audio API that works well with MacOSX, doesn’t mean that it’s a safe model in Linux. Even driver drivers are just asking for trouble. Try doing that in real time environments.”
First, ALSA predates MacOSX. Second, what’s a ‘driver driver’? Third, are you *really* saying that a call back driven model is unsuitable for real time environments? This is the *only* model suitable for a real time environment. I hope that’s a typo, because otherwise, what are you smoking?
When I purchased a SB Live 5.1 sound card about year ago, along with the required speakers, I discovered that OSS didn’t support 5.1 sound, and that ALSA did.
It seems that OSS also requires screwing around with crap like sound servers to get it to accept multiple input channels for cards that don’t do it in hardware.
If I use the ALSA drivers, I get real 5.1 sound, and I can enable software mixing at the system level.
>Its funny that XMMS (another of 4Front’s products that is >GPL’ed and relies on sales of commercial OSS drivers for >paying developers salaries) works better with OSS API >emulation on ALSA drivers than the native ALSA api support.
>This support for XMMS was not written by us but by one of >the ALSA people. So tells you that even the ALSA developers
>have problems writing apps to their own API.
Your payd developer wrote OSS support and you are suprised that it works better as ALSA support writen by maybe hobby programer (who maybe just tryed alsa) ???
>ALSA is not advanced because if it were, we would not be able >to create an ALSA compatibility module that just maps ALSA >high level calls into OSS low level calls
I think this speaks for ALSA and not for OSS. ALSA middle layer is powerfull enough to describe oss driver as alsa soundcard. And I think beter (and cleaner) way is to write ALSA plugin in userspace, which has ALSA api on one size and OSS api on other side.
For others:
Use sound system what you want (OSS or ALSA).
ALSA is in kernel and has OSS emulation. If you don’t like ALSA don’t use it or don’t use distribution with ALSA. You always have choice.
If you have problem write mail to alsa-user mailing list or try irc or fill bug report.
We aren’t saying don’t use ALSA drivers or use only our OSS drivers. We’re talking about APIs. We take objection to people saying that OSS is “deprecated” and should not be used for development anymore without any reason or any idea of reality. We can start saying forget ALSA, everybody should develop to Jack or MAS or GStreamer.
best regards
Dev Mazumdar
Hi all,
the things are not black and white as Dev advertises for OSS/Commercial. You can hardly compare commercial and open source alternative. From my look, ALSA works for almost all things. Yes, our code ocassionally have some bugs which may annoy people, but that’s a life of the open source project. Help us to improve it.
Last months we really concentrated to produce a clean driver code for 2.6 kernel tree.The OSS/Linux code (referring the OSS code in the 2.6 kernel) is not very clean. It’s divided to separate drivers with the separated big portion of the original old Hannu’s code (with it’s midlevel). I’ve never seen the OSS/Commercial code, but I guess when I saw some pieces in the beginning of the OSS/Commercial and OSS/Linux split, they have probably a multi-OS framework to generate code for all OSes they support – not very clean from the open source perspective but rather functional.
ALSA is moving target: No. We (will) retain binary compatibility since 1.00.
Advantage of OSS – can compile everywhere: Hmm, it’s true, but what’s the result of using direct syscalls? You cannot add any feature to the user space to extend the OSS API. For example, creating user space drivers is not easy without LD_PRELOAD hacks and impossible for statically linked applications. We have trouble with this design, because our policy is to move all unnecessary code outside the kernel (like resampling, FX processing, advanced sample routing etc.).
ALSA is not advanced: I believe yes, it is. We have a lot of standartized functions which OSS API is lacking. But it might be that OSS/Commercial v4 will use some of our ideas in their APIs. That’s another part of open source life.
Long names: It’s difficult to name functions with short names in a consistent way for rich APIs.
I will reply to any _technical_ question about our APIs or how ALSA driver/library code is organized.
Jaroslav
I have nothing against ALSA (I personally use it, and I like it – and I think it has far better api as oss -just my opinion). Everything in alsa api has good reason to be as it is. (mostly because alsa suport soundcards from simple mobo to profesional soundcadrs).
I just started to like user space libs and plugin architecture of ALSA.
99% of problems users have with alsa are mixer setting problems.
OSS drivers (free – in kernel) problem is that they are mostly unmaitained (development abadoned). Why not “you” (opensound) maintains in kernel OSS drivers ??? You want OSS in kernel.
Warning: 🙂 ALSA has only 2 payd developers, but they are very good and ALSA is getting better and better.
Really, outside of JACK I don’t think anybody should be promoting the use of sound servers, especially not esound. With a properly set up distribution (unfortunately so far most are not) there should be no issues with audio mixing and resampling as libasound with its dmix/asym family of plugins should do the job.
For OSS apps there is a problem as they must be started as “aoss whatever” in order to be fed into the dmix system, and current desktop environments don’t do this. So, I don’t know what the solution is here except maybe doing mixing in kernel but none of the alsa/kernel devs like that design
I know this is probably not the best forum, and you aren’t responsible for this… but anyway;
Would it be possible to have software mixing _just_work_ out of the box, for applications using both ALSA and OSS? 80% of people have crappy single channel sound cards that will want software mixing. Another 19.9% have hardware mixing cards, that want to use those facilties – until they run of hardware channels. Some people (like me) have both of these in one box.
The other 0.1% who have special requirements can configure whatever funky mixing requirements they require.
Would it be possible to have a default alsa configuration that mirrors this?
Now there’s no reason not to run OSS – because its free (as in free beer) for noncommercial/home use.”
You just stated a reason to not run OSS, it is not GPL’ed like Alsa is.
if you write an app you don’t want to worry about what soundsystem or daemon is on the system that’s why I like gstreamer
app -> gstreamer -> jack -> alsa sound local
app -> gstreamer -> MAS -> alsa sound over network
something like this
as programmer I don’t have to worry what is below gstreamer
My problem was with the standard sound card in P4
machines, the notorious i810..even the lates knoppix
could only say “blah blah defaulting to 2 channel mode”
(I have 5 channel speakers).I sold the machine so I
dont remember all the details..
Ironically my P II with its i710 gives and essox standard
sound card gives better sound than the P4. And all 5
channels are recognized..This under Slack 10 using anything
BUT the default “auto” for sound server in KDE..(and other
window managers)
Too bad its too weak to play dvds..
a little off topic but does anyone know of a linux distro or linux driver that supports Sound Blaster Audigy 1, out of the box?
I only have 2 sound cards for my older PC, an ISA SB32AWE & the PCI audigy. During wine, the ISA SB32AWE craps out (however the sound comes back on when I exit wine.) I want to try out the audigy, but can’t seem to get knoppix to play well with it? Knoppix with kernel 2.4.x
Does OSS support software mixing, so that cards that don’t support hardware mixing don’t require a sound server like artsd?
Basically I’d like transparent support for mixing audio streams, so that applications that don’t support artsd can still play audio while an MP3 is already running in the background.
It is especially annoying when artsd is still waiting itself to timeout, while running a non-artsd powered application. I used to have an icon on my desktop to kill artsd. What about that!
Personally, I have avoided ALSA as long as possible, and I’m still avoiding it on my IBM Thinkpad 600e as it still just does not work.
ALSA never showed any advantages over OSS to me. I’m only using it because it’s “deprecated”. Recently however, I discovered dmix. It’s HELL to setup, but a damn nice solution for cards that don’t do hardware mixing.
Oh and one more thing, is OSS capable of providing “realtime” audio? Afaik this is one of the weak spots of Linux.
I’d just like to see a standard for the sound api so that I can forget about having a special plugin or compilation option for each audio app that makes so much as a beep.
I’d also like drivers for soundcards that don’t do hardware mixing to be written in such a way that software emulation is automatic. I know that the intel8x0 is a piece of crap, but it is a widely used piece of crap.
My other wish is that ALSA wouldn’t mute the sound by default. Maybe a safe mid setting by default?
Other than those issues, I’m much happier with ALSA than OSS. It always seems to support newer cards and after since OSS support was depreciated ALSA seems as easy or easier to set up correctly. Thanks guys.
One technical issue I never understood is this: How can Jack be such a low latency miracle if it rides on top of ALSA? Doesn’t it ADD latency?
jack is not a low latency miracle. Every well coded ALSA or OSS app can achieve the same low latency natively (the app developer has to take care of making the app run in the SCHED_FIFO scheduling class and use small periods/fragments). jack’s real advantage is that
1) it can interconnect many apps. Sure, other sound servers can do this, too but there’s more
2) it is able to use a properly setup system to make all apps in the jack graph have their audio threads run with RT privs with no extra effort of the individual application coder.
3) it has means to synchronize different applications
4) its api is afaik very clean and programming a jack app is soooo easy
with respect to ALSA/OSS i say:
to each his own. i dig alsa for it’s userspace lib power and for its GPL licensing.
hello all, I don’t know where to make the annouce but a very powerfull (up to 32000 track) real time sound editor (very like cubase) has just been open sourced, it comes from
the atari falcon world (DSP, direct to disk, first version of cubase audio on it) and it’s waiting to be ported…
I don’t know about the porting complexity but maybe all the dsp 56001 routine would have to be ported to mmx (I saw one time, some kind of converter existed)
http://www.chez.com/ricard/realisations/english/index.html
(for the site)
and
http://www.chez.com/ricard/realisations/download.htm#download
for the sources…
the binary is usable under aranym (http://aranym.sf.net)
I have not the skills to make the portage by myself but
some wrappers between GEM and X11lib exist…
some guys are already trying to port the source to gcc…
I really hope we could have on linux some of this kind of tool…. (maye just a little painly to install than ardour for exemple)
(A) App >
(B) Software MixerSound System >
(C) Sound DriversCore
As long as contenders for part B come and go (esd, arts, jack, gstreamer) it would be great to bring some sanity into ours lives and build software mixing onto part (C) (ALSA, OSS)
I dont know about Virtual Audio Mixer for OSS.
http://www.opensound.com/virtmix.html
I tried DMIX for ALSA, but it’s a ~!@#$ to set up. Is there any change this can be set up with the system by default?
What’s a ‘driver driver’? He meant “event-driver driver”.
I agree on the TP 600E comment, I fought for 2 days with kernel 2.4 and 2.6, alsa being built in or using alsa-driver, different versions of alsa-driver, etc… all to end up with OSS and esound. The horror is unreal. What is worse, is that the sound is crappy. I know the hardware isn’t great, but at least it sounds normal in windows. And it’s not the apps, nor esound, it makes silly noises regardless of what is playing sound.
Meanwhile on my desktop only alsa builtin to 2.6 works. Go figure. At least I do get to have sound more or less working on both.
> All the major games – Unreal/Doom/Quake still use OSS.
> RealPlayer 10 still uses OSS. OSS isn’t dead yet
> (gosh I sound like Monty Python’s Holy Grail….I’m not
> dead yet….I’m feeling better, I think I’ll go for a walk….)
Well, I believe many games are using SDL to access the system sound; and then SDL, on its own, will look for OSS or ALSA and use either of them where it is appropriate, so, that works both ways.
Also, I have MIDI working with ALSA snd-emu10k1 driver on SB Live! The OSS/Free driver doesn’t seem to have such function.
test
> What’s a ‘driver driver’? He meant “event-driver driver”.
Or maybe ‘event-driven driver’…
New ALSA driver module is available for both Creative soundcards with ALSA 1.0.6, so these cards will function w/ the new ALSA driver in the latest Kernel 2.6.x series:
http://www.linuxquestions.org/questions/showthread.php?s=&threadid=…