Linked by Thom Holwerda on Sat 27th Sep 2008 22:14 UTC, submitted by diegocg
Permalink for comment 331748
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.





Member since:
2008-07-15
Actually, as soon as commercial apps enter the mix the end user usually does have to deal with it, unless they have one of the few hardware multi-channel cards that ALSA actually supports. Most commercial apps use OSS and believe me, ALSA+OSS+PulseAudio is not a trivial setup to get working, seeing as how ALSA's oss layer is basically worthless--nothing sent through it uses any of ALSA's settings, so it pretty much ignores your pulseaudio setup. Sure, you can use padsp or preload whichever DSP library you need, but that doesn't work in all cases--try that in vmWare workstation and see how far you get, for instance. Try it with audacity, you won't get very far. Perhaps OSS did shoot themselves in the foot in regard to their licensing and slow updates--I'd say that's a given. But why did ALSA have to completely redesign the API? For the longest time, ALSA wasn't stable--remember the days of ALSA 0.4 vs 0.5 vs 0.9? Why are the drivers in many cases immature? Why is there no reliable way to switch the default audio device, something so simple? Why is ALSA's software mixing layer so bad that we needed Pulseaudio in the first place? Why is the OSS emulation layer half-baked even after all this time?
The OSS API is stable, standard, and simple. I agree that the Linux audio system needs to be rebuilt from the ground up. If the kernel DEVs don't want to use OSS, at least implement the API properly. It would increase compatibility and decrease frustration all around. Oh, wait, that would take foresight and organization. I guess I was just dreaming.