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

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: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?

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

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

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?