Slashdot Mirror
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."
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.
What I'm listening to now on Pandora...
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.
ALSA was released 6 years ago, and OSS was released even earlier. What's your point?
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.
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..)
world was created 5 seconds before this post as it is.
Linux sound is simplicity itself. How does this article demonstrate that Linux is ready for the desktop again?
Jesus was all right but his disciples were thick and ordinary. -John Lennon
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.
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.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
As far as Linux sound support, I must be 5 years behind the times; and yet, it seems as though nothing has been happening on that front for the past three. What have I missed (besides the obviousness of ALSA)?
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.
Um, the Windows sound APIs are a pretty big mess, actually.
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.
May we never see th
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.
/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?
You want to "dump a file to
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?
May we never see th
On the Microsoft side, DirectX came out nearly 10 years ago...
... that would be, what, ten years after the initial release of Windows 1.0 (we'll ignore DOS for the moment)?
Let's see
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.
May we never see th
The times I have worked with more advanced audio projects on win32 platform it has actually not "pretty much worked" at all. ASIO drivers or Directsound, what driver should I use to make Cubase work good? If you have regular audio applications in mind then I must say that I have not once had a problem with a regular application (music players, soundrecorders, videoplayers etc.) - it Pretty Much Works...
Easiest way to learn it is to read all (outdated, few) documentation and then look for examples and/or API library source code.
If ALSA people want to get their API used (instead of OSS emulation layer) their should bother to write better documentation for it.
Two problems with ALSA are that it is Linux specific, and that its drivers have consistently been worse that the OSS ones for me.
Please correct me if I got my facts wrong.
Does it occur to anyone that applications have to produce sounds on terminals (such as an X terminal) rather than on host machines where they are running?
/dev/audio etc. would be most appropriate (if it's a Unix machine), because this is standard way of communicating with a device in Unix; on top of that there could be a large number of libraries that facilitate processing of audio data - but they should not be considered a part of Unix (Linux) proper.
And indeed, on the machine - a terminal - where the sound needs to be played, using