OSNews

As audio developer, i couldn't more than agree. ALSA is a painful, extremely over-complex api and library in comparison and it really is unnecesary. It handles multiple stream mixing in userland (as opposed to kernel in OSS4), which generates all sort of exclusive access problems when you want to mix low latency and normal latency apps, and makes configuration through asound.conf _HELL_. OSS4 is a much better, simpler, solution and design and since it's opensource now, i can only wish linux distros would start shipping with it and deprecating ALSA. The only good side of ALSA is that it has better support for professional sound cards, although most are, of course, still half implemented anyway.

i've asked myself this same question and seen it on discussions asked by others, the reply they get is invariably: "OSS has been deprecated, development happens on ALSA now"

never mind OSS v4 is a very different thing from the old oss-linux implementation;
never mind OSS4 is a compact implementation of a streamlined, *nix - aligned (open, close, read,write, ioctl, period) and well documented API, while ALSA is complex and overengineered both API AND implementation - wise, and scarcely documented in parts (even pulse audio's author recommends to use a subset of ALSA's features!)
never mind ALSA is actually designed for the lowest common denominator HW and then actually less capable for the beast it is - since it cannot natively do inter application stream mixing even if the HW itself coud perform it (actually, penalizing those who have a decent sound card to settle with those with onboard audio)
never mind OSS(4) is actually more in line with the duties of a kernel like linux generally speaking ( like dealing with more applications accessing a resource at once, letting the resource appear to each one as available - and doing so in a transparent and orthogonal fashion) than something that forces the presence of a user level daemon to a very basic task (by today's standard) like that

lennart poettering has said, that:
"cards capable of HW based mixing are a thing of the past" (of course, creative SB Live, Audigy's and Xfi's dont exist to this day)
"god forbid floating point in the kernel" (now why must the kernel avoid FP ops at all costs is beyond me.. saving and restoring FP registers isnt a big deal IIRC)
and, most important, "an api like that of OSS cannot be virtualized"
(apart from the fact that everybody obviously needs to vityualize the sound card... but read() write() open() close () and ioctl() cannot be virtualized? since when? )
so, as a logical conclusion, "OSS is crap" ...

he's the author of pulse audio, so he apparently is the new guru and director of audio stack development as far as linux is concerned, and his word shall be taken for law... sadness

"lennart poettering has said, that:
"cards capable of HW based mixing are a thing of the past" (of course, creative SB Live, Audigy's and Xfi's dont exist to this day)"

Lives and Audigys are, indeed, things of the past (you can't buy 'em new any more), and the X-Fi still has no practical open source driver.

I want to cry.

By the way, you don't need floating point to mix audio, you just add samples together. You also don't need floating point to resample audio, fixed point works better (and you can even do cubic interpolation almost for free in fixed point by making a delta resampling table). In any case, i still believe alsa should be declared dead. Most of it usage in proaudio was for sequencers and synthesizers, as a (working like crap) midi layer over low latency jack. However, jack api now includes frame-accurate midi, making alsa api obsolete.

Please, deprecate ALSA!!

I couldn't agree more, anyone who's programmed using ALSA, I suspect would agree that OSS is and has always been a much better design.
Right now, the one thing holding back OSS 4 is its drivers. They just don't support quite as many cards and have some quirks where ALSA's drivers do not. In contrast, the drivers themselves are the only good thing about the garbage heap that is ALSA, as the API and Dmix are just total crap.
At the time ALSA was conceived, supposedly it was all due to a licensing problem with OSS/Free. That may be true, but I never understood why we didn't just re-use the API and some of the OSS design. They were good, they worked, and they were simple. Now we have an overcomplicated, multi-layered junk pile that will collapse if you push it just a little bit the wrong way.
Pathetic.

Linux can't include or rely on OSS4 because it isn't even remotely Free Software and is definitely not GPL-compatible, so quit whining about wanting it, because it isn't ever going to happen unless 4Front decides to roll over.

http://www.4front-tech.com/license.html



The 99.9999% of us who do not spend extra cash on add-on cards don't really care if they exist or not. We want audio mixing (without having to restart half our desktop because we just plugged in our USB or Bluetooth headset) using the ac97 and hda-intel drivers that all but a handful of people are using to work perfectly.

You can use PulseAudio because it'll work on top of those higher-end of cards just fine too, albeit without taking advantage of some of its features. Then again, the dmix solution people tout didn't use those hardware features either, and relying on the hardware features means that the second you hit the hardware limits things start to break, because neither ALSA nor OSS can gracefully use both hardware and software mixing based on the hardware profile and actual application sound usage.

You can even use PulseAudio over JACK so your high-end sound apps that actually use those high-end soundcard features work fine and your plain little desktop apps that just want to play an MP3 or a notification sound can also work perfectly.



Strawmen arguments only make it obvious you don't know what you're talking about. You seem to think that the entire software stack is made up of the "driver half" and the "application half." If that's the extent of your knowledge then I guess it's easy to start using "flawed logic" to support claims like yours.

Truth is, software comes in _multiple_ layers, and some things belong in the middle layers. Things like sound buffering so that applications all using the same toolkit with the same Click sound don't need to independently load the sound, decode it, keep it buffered in memory at all times, and stream it to the hardware at the proper rate and with proper buffering (which is hard) every time they play it.

That's just like how X.org includes a Glyph cache shared between apps so text rendering is faster and uses less resources. PA lets applications share a common notification cache so simple toolkit sounds can be played more efficiently and with use less resources.



You are confused. Again.

One and only one thing has been moved into the kernel, and that's the mode setting stuff, for which the soundcard equivalent has always been in kernel and certainly still is when using PulseAisio. The video memory manager work hasn't "moved into" the kernel as that's brand new and has never been a part of userspace either.

Nothing else is moving into the kernel. It's just being shuffled around between the different userspace projects (from X to Mesa to Gallium3D, mostly).



Using someone's innocent and non-serious joke as a personal attack is, unfortunately, not funny at all. Just makes you an ass.

Err... it's GPLed for Linux, BSD-ed for BSD, and CDDLed for Solaris - isn't this open source?

as others have pointed out, 4 front has released OSS4 under the GPL and CDDL licenses, dating june 2007
it's true that some drivers could not be open sourced, though


it doesnt matter
if i was asked to design a system that can work in 100% cases, while eploiting HW features whenever present, and i'm only able to come out with something that works in 99.99% of cases without leveraging HW support for some features, i'd be fired
sometimes i think people in the FOSS world are lucky...


from a wider point of view, implementing HW mixing (or environmental audio for that matter) if supported by HW and hot plugging audio devices if they're SB ones are orthogonal problems you know


this just adds to the argument that ALSA guys have not neen able to design something robust and flexible enough to accomodate ALL cases apart from common, lowest denominator ones...

problem is, if i believe a functional stack is broken by design, i may try to fix it - or more likely i'll avoid touching it with a finger
surely the coupling of a sound daemon with yet another sound daemon is possible, but it's more an abominable mating than an elegant solution
(making them coexist side by side accessing the same low level api's is a bit more elegant, removing the need for sound daemons altogether would be best )

not that it's so unfeasible given current SW technology : shared memory exists, LRPC / fastRPC too...
given shared memory, audio mixing could be done immediately before entering the kernel for IO, using the currently accumulated samples from the various active applications sharing the buffer (or bypassed to be left to the card, if the driver reports the capability)
the sample format could be negotiated once, then converted to the negotiated format before being mixed
then the kernel driver may keep track of whether control commands from some app have completed before switching to another app's (via some sort of fencing)


you've said it right, i may have seemed to think that way
and since english is not my native language, i surely have failed at making myself clear
but trust me, after a decade and some (i'm 32) in SW design i know a bit better than what previously transpired


believe it or not, i perfectly know that...
BUT, if some (say, application) code wants to interact with a SW system providing some service; and can only do so via an API that that hides the system's functionality away and cannot by bypassed; then from the point of view of the application code, it doesnt matter however layered, and inspired by what design concepts, the system beyond that API is - unless its implementation details transpire through the API, of course
this is a tenet of SW design, thus i think it' s out of the question

then, what i meant for "driver layer" is whatever code lies in the path from the application to the target device besides the device layer's driver proper (i've written these same words before, i was hoping to be clear...) because it's intuitive that every element contributes to the behaviour of the stack beyond the audio API, as a whole

now, i really believe having a(nother) daemon mixing audio in userspace is a mistake, since it does something that even alsa alone IIRC was designed to do, introducing a round trip (and an additional serialization over sockets) for every transfer of audio samples, and further decoupling applications from the resource they share
moreover (although maybe i'm a little too obsessed with "optimizing with the local case", as i'd gradly see the demise of Xorg also) network transparency is rarely to hardly needed in a single user desktop use case...


sound buffering is useful, but:
- imho possible events (and notifications) should be evaluated one by one to see which of them would likely be reused fo all applications, then to cache globally, vs which are used by only a subset of applications (e.g "incoming mail") vs which are used for system events; then, caching "categorized" event sounds could be done at the application level, in a library instead of the server (more importantly, not the same server that handles the direct path), sharing across applications could be done and kept in a cross application shared buffer, but it's just a possibility
- ANYWAY, i didn't mention caching;
i despised the rationale for pulse audio to play notification sounds in stead of application events compete to, since IMO reacting to events would be the responsibility of another service belonging to another layer (the desktop shell, or an ad hoc notifier)


can you explain me how X.org glyph cache can help userland SW implementing text rendering internally ?
now that libraries toolkits are following the OGL compositing trend and gradually move away from server based font and primitive rendering, i think that kind of caching will have to be implemented at another level (as fragment shaders, maybe?)


more than moving i actually referred to the streamlining and consolidation process going on on the graphics stack ( that was an example anyway), as opposed to the layering and complication going on on the audio one...


i perfectly know about the state of mesa/gallium3d/DRI2/Xorg (and wayland + eagle btw), since i follow their development closely, thanks


guess i'm too depressed and have too low a sarcasm threshold these days to take innocent jokes for what they are... sorry about that

Ideology... as always...