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

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..)

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.