To view parent comment, click here.
To read all comments associated with this story, please click here.
actually, i don't find it difficult to get a decent working setup with ALSA + JACK. i don't use many OSS-only apps at all. and frankly, there are very few commercial apps written for OSS, in the grand scheme of things. if you're going the commercial-software route, linux is (sadly) not the best platform for audio work.
there are many multi-channel cards with support. admittedly, there are still many very popular interfaces with no support in ALSA. FFADO picks up some of the slack for firewire interfaces. but, the lack of proper drivers (ALSA, OSS, and FFADO) is the fault of the hardware developers for refusing to provide specs. and it's not like OSS has oodles of support from manufacturers that ALSA is lacking.
ultimately, it's pretty simple nowadays to get a decent setup going for multi-track recording. RME and m-audio pci interfaces have decent ALSA drivers, and echo makes some great FW (and PCI) interfaces. add a mixing console, jack and ardour, and you've got a quick and easy recording studio.
it's not that we have a perfect situation... but, if you have a workflow that necessitates commercial software and unsupported hardware, linux just isn't what you should be using right now.
all of this is sort of a silly discussion though. in my original post, i was just trying to point out that for most typical (i.e. non-pro) users, the confusion is really artificial and not at all necessary. for mr. average joe with onboard audio, everything usually just works.
edit: forgot to mention pulseaudio. for any of my studio boxes, pulseaudio is not even installed, or necessary. it's really just ALSA + JACK for me.
Edited 2008-09-28 01:12 UTC
My point wasn't how to set up a recording studio, my point was merely that the end user often does have to deal with it more often than one might think. I agree, Linux is not the platform for commercial software, and if the situation stays like this it never will be. For my intensive audio tasks, I use a Mac.







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.