Introduction to Linux Sound Systems and APIs

UnderScan writes "Linux.com is running an article on Linux kernel sound subsystems, OSS & ALSA, and their APIs. Insightful commentary from both users and the project's developers can be found at OSNews.com comments section."

Comments

This is the problem

[Otter]

The fact that users require an explanation illustrates precisely what the problem is with sound on Linux. Do Windows or MacOS have analogous multiple sound servers that are somehow handled better or have those platforms standardized on a single server? I don't have the slightest idea, and as a user (or a hobbyist programmer), that's precisely how it ought to be.

Re:This is the problem

[molo]

I don't know about MacOS.. but Windows has the standard "multimedia" sound API and the "directSound" API. These are both of course different from the Win16 sound API.

Windows goes through the same type of API revisions.

-molo

Re:This is the problem

[Otter]

I know that there are different APIs you can write to, although not exactly how they compare to the Linux sound servers in terms of low-level access.

But the point is that as a user, it's completely transparent. As a user, it's absurd that I should have to know that sound servers exist, let alone have to kill artsd to hear xmms.

Re:This is the problem

[molo]

Yes, I agree there. There is no reason that any application should ever start up a sound daemon that locks the device. If I wanted to run a sound daemon, I would start it myself.

-molo

I run mostly Japanese-built systems

[Anonymous Coward]

I have never had sound work on any of these machines (NEC, Fujitsu, HPj).

I used to be a team leader back on the initial Unix (read SCO) team, and one thing that we never would have let happen was letting down the Japanese customers by not supporting their hardware.

If there is any one thing holding back Linux uptake, it is the lack of driver support for non-mainstream devices.

Re:I run mostly Japanese-built systems

[Ianoo]

Unfortunately, it's the chicken-and-egg problem (officially known as "Network Externalities"). Hardware manufacturers won't write drivers until lots of people use Linux, and lots of people won't use Linux until there are drivers. What's really needed is the backing of some major coperations to drive development, like say, IBM, or HP, or Nov.... oh wait...

Re:Re-inventing the wheel.

[EnglishTim]

I think the point is that programs using sound under Windows just Pretty Much Work (TM). Sadly I can't say the same for Linux.

Re:Re-inventing the wheel.

[gl4ss]

yes.. work like they control wave out volume of the entire system instead of just their own & etc "just workings"(like there being reasons for why it's good for winamp that it has several audio output plugins each outputting through different apis..).

(I think beos had this covered the best.. being able to control volume per application & etc..)

Moving programs from OSS to ALSA

[linuxkrn]

Being a Gentoo user, I've been running ALSA for some time. While ALSA has an OSS compat API that you can load, it doesn't allow you to have the full control of more advance cards. (Like the EMU10k1/2 chipsets)

While oss-compat-api will give you basic sound, mixer controls, etc. sometimes you want to do more advanced things. For example, I use a tvtuner app and wanted to be able to control detailed mixer channels (Analog Capture Volume and Analog Playback Volume) that just couldn't be done with OSS. Looking at my app, tvtime, I found it only had OSS mixer controls. So I just took a weekend to learned/wrote the ALSA API version for it. Wasn't too bad and the app works great now. I can configure any control (mixer channel) on any card I want. Hopefully the dev will include the patch I sent it in the 1.0 release this month.

I know that this isn't an option for everyone. But I think as time goes on, more and more apps should have support for ALSA. Especially since it's in the 1.0.x range and the API has become more stable.

Re:Moving programs from OSS to ALSA

[Omega1045]

I had a lot of problems installing a new card based on EMU10k. In the end I had to go into the Kernel and turn off ALSA and turn on OSS, and it had the "driver" right there. Compile, reboot, sound works! However, this proves yet again that while Linux is a great desktop (I use it for my home machine), it is not "ready for the desktop". This is not to throw blame at anyone. But sound should be seemless, or at least very easy to configure with a GUI tool.

I would not be against taking some developer resources away from progress on the kernel, etc, and have them work on drivers and configuration applications for sound, video, modem, network, vpn, etc.

Perhaps IBM and the other big players could fund a team that ONLY develops drivers for these standard services, and a plug-and-play type of detection module that really does work. Take every know video card, sound card, network card out there and get them to work?

Re:Moving programs from OSS to ALSA

[simcop2387]

I would not be against taking some developer resources away from progress on the kernel, etc, and have them work on drivers and configuration applications for sound, video, modem, network, vpn, etc.

the problem there is that lots of people ([i think] including myself) see this as a distro problem and beyond the scope of the kernel where most of this has moved (i think the vpn thing isn't though). And as you said making applications for configuring sound, video, etc. this is usually done at the distro level, i know that suse did it pretty well but i dont think they had autodetection.

Take every know video card, sound card, network card out there and get them to work?
the problem with this is that the manufactures of those cards are typically not very coopritave(sp?) and that means that you have to have the hardware and reverse engineer the whole thing to get it working.

these systems are junk

[XO]

The Audio subsystems are junk. Mixing should be handled intelligently by the drivers, and it should be standard unix systems used to access it. You want to play a file, you dump it to /dev/audio, you want to record something, you open /dev/mic or /dev/linein and and record it.

Additional controls should be handled by ioctls to the special devices.

The sound system in Linux is a nightmare.

Just copy Core Audio and be done with it

[tigeba]

Perhaps Linux developers should take a whack at emulating/copying OSX Core audio. It might provide an incentive for application developers to port their audio apps to Linux.

Re:Just copy Core Audio and be done with it

[Unknown Lamer]

JACK uses a callback based API much like Core Audio.

Basically every high-end (e.g. ardour, JAMin, Rosegarden, Hydrogen, etc.) uses it.

You can get really low latency using it if you have good sound hardware (e.g. RME Hammerfall for extremely low latency or even an M-Audio Delta 1010). Something like an SBLive! (what I have) will need a period size of 2048 bytes with two periods to avoid underrunning (I have a Dual AthlonMP 2800+ so I'm pretty sure it's the sound card...). Stuff like QJackCtl and Jack-Rack make controlling Jack easy.

Getting realtime mode working for a normal user can be tricky, but Debian makes it really easy. Just install the realtime-lsm package and build the realtime-lsm-source package for your kernel and all users in the audio group gain the ability to run applications realtime (at least with the default config). It could be made easier (mainly by prebuilding the realtime-lsm modules for the stock kernels) but GNU/Linux pro-audio is still mostly for hackers and adventurous people right now. Stuff like PlanetCCRMA and AGNULA are aiming to make everything work out of the box. I have yet to try either (I use Debian so PlanetCCRMA is useless for me) but it looks like DeMuDi has everything set up for recording out of the box.

Re:Just copy Core Audio and be done with it

[tigeba]

I agree that low latency is quite important, and anything that furthers that goal is a good
thing. Even the really good native systems still arent quite up to the task of recording lots of live musicians, which is why for now I use Protools HD on OSX.

I was recommending implementing CoreAudio (or heck Direct Sound) instead of something just similar because it would decrease the level of effort for the developers of the applications (and very importantly plugin developers). It would just be a case of recompile-and-pray vs recode-recompile-pray, which might make it feasible to get some of these great high-end apps on linux.

What's happened in the last few years

[0x0d0a]

Oh, let's see:

* The OpenAL library came around. Does 3d audio, hardware mixing, doppler, etc, etc. Good for games.

* OSS/Free got deprecated.

* The plethora of eight million halfassed sound servers resolved down into just a few -- artsd is probably going away in favor of JACK (if the article is correct), which means that we just have the (icky) esound -- which with any luck will give way to JACK -- and JACK. Finally, applications can avoid having eight million output plugins.

* Hardware mixing in drivers became par for the course. Five years ago, everyone used OSS/Free. Today, you can play audio in xmms and *still* hear your "bong" when an error occurs without having to ram everything through a high-latency sound server.

* Wavetable MIDI is, at long last, reasonably well supported. I remember the early days with my emu10k1-based Sound Blaster Live Value and earlier cards where I had to just use FM synth because I couldn't load soundfonts to my card. Linux was behind for years here.

* Creative Labs is no longer ignoring Linux users.

* At least in theory, I can use the DSP on my emu10k1 chip to do things like adjust bass.

* There are half-decent sound applications out there. Rosegarden doesn't suck, there are synths and trackers and editors. Still not the same as a Windows or MacOS-based sound editing environment, but you can actually do sound work on Linux without coding up your own tools. :-)

I actually really like Linux as a sound-using environment. I can plonk two or three sound cards into a Linux system and (unlike Windows) all my apps let me choose what device to play out of. I can be playing music going to speakers out of Sound Card A for everyone in a room, but still be listening to what someone's saying on VoIP over my headphones connected to Sound Card B.

I don't think it's as bad as you make it out to be

[0x0d0a]

Ever used a system with multiple sound cards? I have, and I'm not even an audio engineer. That approach wouldn't work very well for it.

You want to "dump a file to /dev/audio"? What format would be used? Linear or logarithmic encoding? What if the sound card does MP3 decompression onboard -- how do you get MP3 data to it? How do you detect whether to use 44.1 or 48kHz? Am I unable to set bass enhancement from the command line? What if I want to play a MIDI? What about cards that have a front and rear stereo channel -- where does what go?

I'm not saying that these are insoluable, just that there's a bit more complexity than you're making out.

How would you implement "mixing should be handled intelligently"? This is something that I've thought and bitched about for a while. The ideal would be to automatically use hardware mixing up to the maximum number of channels (two on an old card I had, 32 on my current Sound Blaster Live), then fall back to software mixing. The problem is that you have to have some buffer space to mix audio, which means adding latency. When you hit 33 channels and that last channel has to be software-mixed, what are you going to do -- suddenly bump up the latency in the audio to add a buffer into the audio output line? Right in the middle of playback?

Re:Re-inventing the wheel.

[0x0d0a]

On the Microsoft side, DirectX came out nearly 10 years ago...

Let's see ... that would be, what, ten years after the initial release of Windows 1.0 (we'll ignore DOS for the moment)?

And DirectX is comparable to SDL, not to ALSA/OSS. How many years after Linux was in a releasable form did SDL come out?

ALSA/OSS is a driver revamp. I do believe Microsoft underwent a pretty thorough throwing out of drivers when they ended the 9x line and moved to the NT line completely.