Slashdot Mirror
State of Sound Development On Linux Not So Sorry After All
An anonymous reader writes "There have been past claims by Adobe and others that development on Linux is a jungle, particularly with regards to audio. However today, the author of the popular 'The Sorry State of Sound in Linux' has posted a follow up showing Adobe's claims to be FUD, as well as being a good update on where OSS and ALSA are holding today, and why PulseAudio isn't a good idea."
I can't speak for Logic Pro, but there is a (VERY good) alternative to Pro Tools; Ardour. The ubuntustudio packages had everything I needed to jump right into a professional DAW. I've been using it for high-quality recording/editing for almost a year now, no problems.
In theory pulseaudio is great. In practice, it sucks. Nevermind, it sucks in theory too :(
Yes, Linux audio sucks. If nothing else, we have three common and incompatible APIs to perform a single tasks, and none of them are definitively better than the others. So, my question: what exactly is it that we're trying to achieve? What's the end goal of creating newer APIs instead of perfecting the old ones, such as moving from OSS to ALSA to whatever they roll out this month?
For comparison, FreeBSD uses multi-channel OSS. You can have a whole passel of processes writing to /dev/dsp simultaneously, because whenever a process attempts to open it, the OS spawns off a new copy. It Just Works. I'm a little amazed that my FreeBSD server's sound handling is so much better than my Linux desktop's and requires approximate zero client configuration. So again, what was Linux hoping to achieve by dropping old "obsolete" OSS in favor of increasingly complex solutions?
Dewey, what part of this looks like authorities should be involved?
Pulse Audio is a bloody disaster. It breaks just about every audio application I have, and even when its not running, it creates over runs and under runs in other ALSA and SDL audio applications (like ZSNES). ALSA, and SDL audio was the perfect sound abstraction system. Pulse Audio screws EVERYTHING up. I have to makle my own patched RPMs to get rid of Pulse Audio hooks in applications. Its bad. Its really bad.
Audio applications should use ALSA but not lock the card. Games should use SDL. Everyone else should follow suit.
If an application is locking a card its the drivers fault. Fix the driver, fix the over runs, and ditch Pulse Audio!
The real problem here was created when developers started trying to solve the mixing issue by writing software libraries instead of a specification.
Instead of attempting to write a one size fits all sound library that would interface directly with the sound hardware and provide the direct interface for applications who wish to play sound, what they should have been done was drafting a specification for an API that contains only the most basic audio features (creation of primary / secondary audio buffers, enumerating supported device buffer formats, etc.). The driver provides the implementation for the specification. If the device driver indicates the device is capable of hardware mixing, it should use hardware mixing internally, if it doesn't, it uses software mixing internally, if supports the use of hardware buffers for secondary buffers it can do so, but this all will take place within within the driver specific implementation of the standard specification. This should have been paired with a robust generic open source driver that (hopefully) supported as many generic audio devices as possible. Using the interface exposed by the spec directly might seem a little low level, but additional software libraries could be built on top of that interface for use by applications. The important advantage if they had gone down THIS road is that the single conduit, the arbiter of all things audio in the system would've been the device driver for the sound hardware, which would reside neatly in the kernel.
... when application developers or users express concern about a problem in your OS is to attack them, call them liars and FUD rakers, accuse them of being stooges for Microsoft or whatever.
I'm pretty sure the engineer who develops the Flash Linux player is probably on your side, and he was expressing a legitimate concern about a problem with Linux. As best I remember Adobe hired him out of the open source, Linux world. It would probably be more productive to listen to his concerns, and see if maybe, just maybe, there is a problem with audio on Linux. Having tried to write simple audio apps myself using OSS and ALSA I can assure you they have issues, OSS having no mixer at all was a nightmare to make play with more than one audio stream or more than one app at a time, that's why ESD, arts and pulse were created to hide these mixer deficiencies.
ALSA is a ridiculously overdone, convoluted audio API which makes it very painful for audio driver writers and application developers alike. It simply has too many knobs that can be tweaked and turned most of which never get implemented properly by driver writers and can't be trusted.
The simple fact that there must be a dozen different audio API's on Linux many of which exist solely to hide applications and users from the deficiencies in OSS and ALSA tells you something right there.
Rather than attacking this guy maybe you should have the empathy for the guy, he has to deploy an application that is used by probably millions of Linux users, most of whom are ticked off its not open source in the first place and then when it doesn't work perfectly they scream bloody murder. He has to try to make audio work in the face of the fact there are countless barely working or at least buggy ALSA drivers in the world, and there must be about a HUNDRED different ways to configure audio when you count OSS, ALSA, gstreamer, pulse, esd, arts, jack, OpenAL, and a MILLION different configurations when you count all the obscure options you can or in some cases HAVE to set on audio drivers.
As an end user I've suffered through painful, hard to fix audio bugs, in just about every PC I've owned over the last ten years due to audio driver bugs. Sure I could sift through "supported" hardware lists and try to find that rare new PC or laptop where everything is guaranteed to work on Linux, but I would actually prefer to just buy the hardware I want at the price I want. Of course in all fairness to the Linux developer community it is a total bitch to get working drivers on all the PC hardware being put out especially when the vast majority of hardware developers either just don't support Linux, support Linux badly, or actively obstruct Linux support.
You all seriously need to realize that if you want broader acceptance of your wonderful operating system:
A. You need applications and application developers to develop for your system, and not attack them if they point out problems deploying apps on your system. In a perfect world every app would be open source, but there may be some apps which aren't Linux would be better off having as closed source than not having at all.
B. it will have to actually work for ordinary people who aren't going to spend days/weeks/years fiddling with things to try to make it work right.
One of the beauties of the Mac is the hardware is tightly controlled. You may view that as confining and depriving you of your freedom, but it also helps insure the damn thing works out of the box, and most of the applications on it work pretty damn well. After years of fighting nagging bugs on Linux I decided it was in my own best interest to just switch to a Mac for my desktop system and I use my Linux box solely to develop code on. Linux on the desktop is a lot better than it was but unfortunately its just not a very good desktop experience by comparison.
Unless there is a major attitude adjustment in the Linux community that is unlikely to change. Either:
A. Be content that Linux is a niche OS for hardcore fans a
@de_machina
Wait. Claiming audio sucks on Linux is FUD because there's not one, not two, but three mutually incompatible and redundant APIs? How the hell is this not a clusterfuck?
Oh I'm sure there's some reason why someone prefers one to the other, but seriously. You're sending bits to a soundcard. That's it. Just make one API and be done with it. Got a beef with the API? Enhance it, don't just throw it away?
My god, audio was one of the reasons why I ditched Linux for a mac four years ago after running it as my primary OS for ten years prior. Frankly I got tired of having sound work in some applications, but not others. I got tired of guessing which mixer would adjust the sound, which mixer wouldn't. I got tired of seeing "No ALSA cards detected" in my startup, but someone how having `alsamixer` be the one mixer that worked most consistently.
This is a mess made by the developer community and developer community has so far failed to show that it is capable of solving it. If only there were a Benevolent Dictator or something...
LOL!
Every 'bearded GNU freak' has two machines:
1. And ideologically pure Linux machine that he posts +5 Insightful diatribes calling for blood with the smallest hint of GNU copyright infringing stories.
2. An unspoken Windows box that he plays World of Warcraft and other games on while downloading hundreds of gigs of copyright infringing music on.
There should always be sound mixing, with no ifs, buts, exceptions, or configuration required. It should be there by default for anything that tries to play sound
There is. ALSA's dmix has been enabled by default for a long time, years. Have you even tried Linux? I can't remember the last time I had to 'configure' sound on Linux. Insert sound card, mixer shows up, play sounds. From the ALSA wiki: "NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix. Dmix is enabled as default for soundcards which don't support hw mixing."
The result of this nonsense is that crap like pulseaudio continues to exist
No. Sadly, pulseaudio exists simply to copy Vista. Vista introduced per-application mixers and apparently this is a Cool New Feature that everybody supposedly wants, even if it's a shitty implementation that slows down what was a perfectly working sound system.
Is there any document out there which explains why /dev/dsp doesn't get mixing with ALSA?
If you bothered to try, you'd find that it does.
Being able to play sound over the network is OK I guess. BUT THE VAST MAJORITY OF USERS JUST WANT SOUND TO AT LEAST WORK LOCALLY FIRST - then get the network to work. For example, I just purchased a mic so I can use Skype. The mic works - I hear my voice - but it doesn't record. How frigging hard is it to record from the one input labeled mic?!? Tons of instructions - all of them different - none of them work. Meanwhile some pimple headed Linux geek is still trying to get sound over the network working...
Sheesh, the guy has *one* thing in his life that gives him joy, and you guys have to go and spoil it. Perhaps you could show a bit more courtesy if he ever brings up mounting/unmounting filesystems on the fly...
Yeah, it's supposed to work, but for some reason for me it doesn't.
And have you looked at that page? It's full of listings of arcane incantations. Really, I just want the darn audio to always get mixed, without having to get a degree in audio engineering to understand what's going on there.
See the dmix page, which says "Normally (without hardware mixing) you cannot use /dev/dsp multiple times directly."
So it seems that if you have onboard audio, and want to have more than one app use /dev/dsp, you're out of luck.