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."
If Pulse Audio really sucks, then Linux Audio really is in a sorry state .
I commend you for at least customizing your troll to the story. So few bother these days.
When I no longer have to reboot into OS X to do real multimedia production work, then I'll agree that alsa has arrived. But this self-congratulation party is way premature. Linux has nothing that can even begin to rival GarageBand, what to speak of Logic Pro or Pro Tools. I surely wish it were otherwise. In fact, I just got done spending hours fooling with the Pro Audio overlay for Gentoo, and couldn't even get Hydrogen to play nice with or without jackd. Yes, my soundcard is listed as "supported".
Caveat Utilitor
I don't have any problems getting the modules to load, it's the quality of the output that's lacking for me (NForce4 chipset). Popping (DC bias) as you slide the volume fader up and down, as well as throughout playback is unbearable. Not to mention the state of media players on Linux...
Really, it is.
It can be a pain in the ass to get working still, and is buggy.
I'm sure it works well for some, but many others still have 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?
And that is that ALSA's way of handling mixing is completely moronic.
As an user, I care about hearing sound first of all. Sound quality (no pops or crackles) comes second, latency comes third.
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, whether through ALSA or the OSS backwards compatibility.
The result of this nonsense is that crap like pulseaudio continues to exist, which is CPU hungry, often skips, fails to work with some programs and crashes frequently (what the hell is up with that?).
Is there any document out there which explains why /dev/dsp doesn't get mixing with ALSA? And why nobody tried to patch that yet?
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!
ALSA was a big mistake, from the same mold as the Netscape "Let's throw everything away and start again!" that Jamie Zawinski complained about all those years ago. For some reason the ALSA developers decided that OSS sucked but rather than fix the few issues that existed, they threw it all away and created this huge monster called ALSA. There are some nice ideas in there, such as generic PCM buffer management, but there is no reason those features could not have been added to the existing OSS implementation. OSSv4 proves that it was possible. Instead Linux has plumped for a system that is too complex, poorly supported, poorly documented and disliked by developers. If instead the effort had been applied to fixing OSS, sound on Linux would now be further ahead than it is now. Now that OSSv4 is fully GPL I'd love to see it back in the mainline tree, at least to give users better choice, but sadly I suspect there are some major egos and political posturing that will stop that happening.
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.
Not to mention the state of media players on Linux...
Going a little bit off-topic first: a cousin of mine had Ubuntu on his laptop (featuring a Geforce 9300M G) and couldn't get rid of image tearing in VLC. Who would be the culprit in this case? The video drivers or the media player? I have kept wondering since then and my enquiring mind would like to know.
At any rate, could you please elaborate? What makes media players bad under Linux?
"The body may heal, but the mind is not always so resilient." -- Deus Ex: Human Revolution
I hate PA. It's a complex mess and half the time it just doesn't want to work right. There is no way your average user could deal with it. Most of the time I have trouble with it not allowing multiple users to have audio at the same time seemingly due to some twisted sense of how security should work. ALSA is better than PA but still doesn't work a lot of the time.
It sounds like OSS is getting it's act together and just needs someone to hire the lead developer(s) and port all cards missing OSS support over. That sounds like a worthy goal for those selling distros or soundcards. If it works well and is easy for developers then it'll work well for end users. That is what matters. Sound has been my #1 embarrassment when pushing Linux. It has never worked well and it's time we get it fixed.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Both the Adobe article and the "Sorry State Of Sound" article date from May 2007. The new article reinforces that the state *was* sorry then.
Troll. I lolled.
About a gazillion years of linux use lie behind that comment. I love linux to death, its the greatest thing to have happened to 'PC' since .... ever.
The irony lies in the fact that modprobe - in fact the whole, loading unloading kernal modules on the fly - is nothing short of amazing.
I can't think of anything more impressive (in context) than being able to dynamically modify the core OS behaviour through a simple set of command line tools.
The only problem that remains is that 'everyone else' doesn't ever want to even know that stuff is possible.
Invaders must die
Troll?!? What the FUCK slashdot? This is a legitimate complaint and question, not a troll. Off-topic may have been a valid mod, but troll? Seriously, fanboys, take Linus' cock out of your mouth for a few seconds and get a breath of fresh air. You guys are just as bad as the worst apple and microsoft fanboys.
TFA says that the way sound is implemented in the kernel is basically okay, but there are problems with how the kernel's facilities are used at higher levels by applications, and with the way the whole thing is integrated by distros. I think he's basically correct.
As an example of what's not broke about the kernel, and doesn't need to be fixed, it's a good thing that we still have support for OSS. OSS allows you to do sound I/O in exactly the way you would expect to do sound I/O based on the fundamental design principles of unix. You just do open(), ioctl(), read() or write() on devices like /dev/dsp. If you couldn't do that, it would be a failure to do the obvious, straightforward stuff to handle sound in the Unix Way.
As an example of what is broken at higher levels: I run Ubuntu Jaunty. Sound works fine every time I boot the computer, and I get the bongo sound as the login screen comes up. Then when I log in, master playback is muted, and the volume is down at 1/31. Also, the way the Gnome icon shows me that sound is muted (a tiny red box with a white x in it) is the same as the way the network icon would show me that I'd disconnected my ethernet cable or something; in other words, it makes it look like it's not just muted, but actually broken. Here's my best attempt to characterize the bug: Here's a bug on launchpad that may or may not be the same thing:
Find free books.
... 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...
Whoever modded you a troll is a moron.
The problem is most likely the video drivers. Download updates from NVidia's website. The free drivers for NVidia cards will get your display working, but it won't be fast.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
The developer of PulseAudio explains some of the rationale in this interview.
-- Ed Avis ed@membled.com
The main reason why PulseAudio isn't a good idea:
It is just the best possible counterexample of "Just Works(tm)". In other terms: each time I try it, it just "Doesn't Work(tm)". Without it, sound works more often than not; I don't care why or how as long as it does work. Simple observation: "apt-get install pulseaudio" breaks audio, "dpkg --purge pulseaudio" repairs audio.
Hm. Maybe that's how Linux audio is supposed to be brought to a (relatively) sane state: by breaking it so terribly that rolling everything back to the previous state would almost look like a step forward.
No it doesn't - it works for me.
I use an obscure distro called "Ubuntu" that halfway switched to PulseAudio during the latest release, breaking half the audio on my system until I uninstalled it. PA might be a great thing but the current state of it, right now, today, on the most common Linux systems, ain't so hot.
You're an idiot and/or a Microsoft astroturfer.
Cute, kid. Run along.
Dewey, what part of this looks like authorities should be involved?
Over the years I had a lot of prolbems with ALSA, the biggest being the lack of sound mixing with the sound card on my motherboard. To get around it, I went out and bought a different sound card that supported hardware mixing. I still had problems where ALSA would just break periodically and require restarting it. Then at one point it just plain broke and nothing would fix it.
I had enough and installed OSS. What a difference. Latency is better and it just works. There is no excuse to not providing consistent audio mixing. I should have switched to OSS in the beginning rather than buy an expensive sound card because ALSA couldn't do software mixing.
A sound API should provide sufficient abstraction so that basic operations do not depend on the underlying hardware. Mixing, sample rate conversion (when needed) and per-application volume settings fall under basic operation as far as I'm concerned.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
My chief complaint, both on Windows and Linux is that probably 99% of applications have no concept of anything other than the default sound card, making multiple cards useless for all but a few niche applications. Apps that use sound need to provide a way to specify which device is used in case the user wants to use other than the default, period. None of the solutions for audio so far have really done anything to make this better (or they make it worse in the process) - granted, it's mostly an application issue, but control of device selection in the mixer as well would help.
Yes, go on, which one? Depending on your distribution, you might need to install the pulseaudio module for VLC, but that's only a few clicks.
At least get your zealotry straight.
The "bearded GNU freaks" wouldn't dare touch World of Warcraft. It's proprietary! It certainly isn't "Free as in Freedom"!
Don't thank God, thank a doctor!
My guess is compiz. Install compizconfig-settings-manager, open it, go to "General" and tick "Sync to VBlank" in the "Display Settings" tab. The newer UXA-mode Intel driver may have problems with this, but for other cards this should make everything look better.
Bottomline for the topic under discussion: you never know.
The state you are in while your HEAD is detached... - wait, what?
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.
All modern operating systems offer this functionality, most from the command line (ie on OS X it's kextload/kextunload). It's not some amazing Linux thing.
I upgraded to Jaunty and expected a lot of trouble.
Where is my audio trouble? I was promised audio trouble. Where is it?
The trolls said that I my sound wouldn't work anymore. What happened?
A Pirate and a Puritan look the same on a balance sheet.
It's a neat feature. But hardly novel or really that amazing. Other Unices offered this, and I'd be surprised if mainframe systems going back 30 years didn't. Heck, SunOS (the predecessor to Solaris) offered this, and it was end-of-life'd before Linux 0.1 was a gleam in any Finn's eye.
Linux 0.01 was released in September 1991. Linux 0.11 was released in December 1991.
The last release of SunOS (4.1.4) was in November 1994. It was supported by Sun until September 2003. Never underestimate the demand for long term commercial Unix support.
App -> libao -> OSS API -> OSS Back-end - Good sound, low latency.
App -> libao -> OSS API -> ALSA Back-end - Good sound, minor latency.
App -> libao -> ALSA API -> OSS Back-end - Good sound, low latency.
App -> libao -> ALSA API -> ALSA Back-end - Bad sound, horrible latency.
App -> SDL -> OSS API -> OSS Back-end - Good sound, really low latency.
App -> SDL -> OSS API -> ALSA Back-end - Good sound, minor latency.
App -> SDL -> ALSA API -> OSS Back-end - Good sound, low latency.
App -> SDL -> ALSA API -> ALSA Back-end - Good sound, minor latency.
App -> OpenAL -> OSS API -> OSS Back-end - Great sound, really low latency.
App -> OpenAL -> OSS API -> ALSA Back-end - Adequate sound, bad latency.
App -> OpenAL -> ALSA API -> OSS Back-end - Bad sound, bad latency.
App -> OpenAL -> ALSA API -> ALSA Back-end - Adequate sound, bad latency.
App -> OSS API -> OSS Back-end - Great sound, really low latency.
App -> OSS API -> ALSA Back-end - Good sound, minor latency.
App -> ALSA API -> OSS Back-end - Great sound, low latency.
App -> ALSA API -> ALSA Back-end - Good sound, bad latency.
Do you by any chance buy Monster cables, and a wooden volume knob, because it "sounds better"?
I'm sorry, but without proper ABX tests, I do not believe a single word of this table.
And about the latency: Please enlighten us, how you actually measured them?
Any sufficiently advanced intelligence is indistinguishable from stupidity.
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...
I'm sure from all the rave reviews it's technically superior and all, but right now it's controlled by a paranoid schizo who hasn't got a clue how open source works: after GPLing it and whining that he hasn't suddenly started making money, he now thinks he can dictate what license apps using his API have to be released under.
Try using the OpenGL output driver, and make sure 'wait for vertical blank' (vsync) or a similarly-worded option is enabled.
I use the Nvidia drivers and also have tearing issues with any full screen video. I use Xfce with the Xfwm window manager. The tearing goes away if I both disable compositing (the Gnome equivalent would be to not use Compiz, I believe) and set vsync to the monitor the video is on in nvidia-settings under "X Server XVideo Settings". (I have two monitors with slightly different vsyncs -- I have yet to find a way to play full screen video on both monitors with no tearing on either but I have also yet to figure why I would want to do so other than testing my video card. ;-)
My current usage pattern involves disabling compositing (it's just a checkbox in the window manager settings for Xfwm) whenever I am watching a video with enough action for the tearing to bother me and reenabling it when I am done (as the window manager performance is significantly better with compositing enabled), which is annoying but works. Hopefully at some point to issue will be fixed -- or maybe there is already a way to get video without tearing while compositing is enabled that I am not aware of?
Centralization breaks the internet.
Works as a DAW for me. Realtime kernel, Freebob, Jack, Qjackctl, Ardour. I wouldn't describe my audio work as taxing but it's certainly a capable setup. The only caveat is you probably need to understand more about how it's all plumbed together than on OS-X.
Looking at the charts, and looking in a few other places, it is clear to me that OSSv4 is the way to go.
So, when does this start to happen? I tried this a few months ago, and I had to patch my kernel and do all sorts of other things that ended up hosing sound completely (since I'm not a developer, asking me to do developer-ly things is trouble).
When will it be a simple switch in the kernel config, or a simple matter of installing a package in the major distros?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
First off, KDE and Gnome != Linux. Last time I checked they both ran on FreeBSD too. They are the real problem. When I first started playing with sound on Linux (probably 1996 or so), OSS was the established standard for the kernel. I think there were some other devices for compatibility, but Linux developers used OSS.
Then around 2000 or so, ALSA started to show up as a viable project. It supported low latency sound and was more reliable for syncing sound to video. Obviously, you want this for playing video games or watching movies. Quite a few distro maintainers jumped on it and added it to their distro before it was added into the mainline kernel. Eventually it was added, and they kept OSS for backwards compatibility.
Until recently, yes, Linux didn't support multichannel audio, but now ALSA does, and it does "just work." Most of those daemons were created to patch on support for multichannel and networking. I assume those must be the "incompatible APIs" you were talking about.
There is one daemon called jack which seems to be good for audio editing--it is a whole routing system for audio, but I doubt one would need to use it for just playing sound since ALSA seems to have all the features, and ALSA was never superseded by anything else like you implied. Jack, esd, pulseaudio, artsd (unless it uses esd), & etc all use ALSA.
I'm having difficulty understanding where you're coming from regarding the media players in Linux. For audio, Amarok 1.4 is nothing short of amazing. Even the venerable Winamp and Foobar can't touch it for flexibility and keyboard friendliness. As for video players, mplayer is one of the programs I fire up to show Linux off to Windows using naysayers. It loads anything you throw at it and it's blazing fast at seeking, start-up, you name it. And if you just have to have a GUI, VLC is untouchable. Hell, Miro will play your local videos too and it has tons of features. I know that all of the video programs I mentioned run under Windows too but, to imply that media players on Linux suck is disingenuous at best.
The soylentnews experiment has been a dismal failure.
Pretty sure VLC doesn't do hardware acceleration on any platform period. Nvidia supports VDPAU in linux which allows you to play HD flawlessly with practically any card as long as the video player supports it (and a number do, mplayer and XBMC are two that come to mind off the top of my head).
See: http://www.phoronix.com/scan.php?page=article&item=nvidia_vdpau_gpu&num=1
I agree. I think it has more to do with some kernel developers who refuse to consider OSS after OSS3.
The OSS kernel interface is simple and the audio mixing is performed in the kernel (if needed) where it should be. All an app needs to do is open /dev/dsp and perform a few ioctl calls and they're ready to go. They don't need to care whether some other application is also playing audio or not.
It's much cleaner than ALSA, which is a mess IMO. I've had a lot of problems with ALSA until I finally dumped it for OSS4 which solved the constant clicking, stuttering and lack of audio mixing. ALSA would often need to be restarted and it finally got to the point after a kernel upgrade where ALSA just plain refused to work at all.
With OSS I can basically choose the format of the audio, the sample rate and the volume and just set it and go. If the hardware doesn't support multi-stream mixing and volume then OSS does it in software. Similarly, if the hardware doesn't support the sample rate (i.e. 44100) then OSS will resample it to match the hardware, thus abstracting the hardware from the software, which is the way it should be.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
I have to wonder what program you are using to output the audio. On my desktop, there are settings that allow the audio to be routed immediately to output without processing in PulseAudio or anything.
But, more to the point, your latency relies on the program itself much more. I've been doing quite a bit of low-latency audio programming using both ALSA and PulseAudio, and they both get extremely small if you know what you're doing. With ALSA, I've gotten to around 1ms, while I can easily get PulseAudio to approximately 5ms. Using a PC that has two cores, I've gotten the numbers cut down to around 0.5ms and 2ms, respectively.
If you're having a real touchy time getting response that low, you likely have to bump up priority of the process. Using ALSA, simply setting the application to realtime scheduling will do it. With PulseAudio, you're going to need to set the audio server itself to realtime as well as the application (I haven't done too much testing with that, but that seems to be the consensus online). As a parent suggested, you probably want to look at using JACK. It does most of the dirty work for you.
I learned most of this working on a low-latency audio application. Just yesterday I got the thing to route a guitar at low latency using ALSA, and I'm looking to finish up the Pulse portion this next week or so.
While Amarok is indeed the best Linux media player available, it's still terrible, sorry.
The free open source drivers for ATI card have been supporting tear free video for a long time now.
How the FUCK is this +5 Interesting?!? It's COMPLETELY offtopic, AS HE ADMITS.
And to answer the parent's question, it's probably the video driver, try out mplayer with opengl output.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
A single bad moderation doesn't make a bad community. Hell, they're modded 4 at the moment. Let the system do its job.
Bye!
So maybe this isn't a good time to mention that you can upgrade video drivers in Vista (and above), or recover from a video display crash, without even closing and reopening your windows, never mind the applications behind them?
That said, I don't know how to force WIndows to load or unload a kernel module (.sys file, typically) via command line. It's probably possible, but Linux certainly does make it easy.
There's no place I could be, since I've found Serenity...
I do, actually after I post this I'll be using it to produce a Jazz album that I also recorded on a linux machine (Fedora, ccrma). I think Jack is great to hook up different audio applications and I think the resulting production process is a real step forward from existing digital mixing/mastering processes. Not perfect, sure, but I'm not certain it can be duplicated on Mac's and windows boxen.
I've produced three albums so far under linux and the software has come forwards significantly since I started playing around with it in 2003.
In recording mode - where it matters most - I have a machine that is stable because if there are any problems during the recording the musicians are not likely to be understanding. Usually the machine is set to record over a day or two with 16 channels of input and very little interference. The underlying features that a Linux box offers like LVM's, fast file systems like reiserfs, tunable kernels are a bit of a hassle to set up at first but the result is an exceptionally stable system.
There are shortcomings but I just develop new habits to overcome them. With the money I saved on a mac and protools I have bought some great recording equipment. I plan to start donating to the Ardour and jack projects because that is what they need to improve and make them progress a lot faster.
Without the Alsa project as a foundation I don't think any of the sound projects happening now under linux would have been possible.
My ism, it's full of beliefs.
If we switch to OSSv4, people will start whining because we will have three sound systems instead of two. A gift for all Linux FUD spreaders. Drivers quality will not improve in the switch from ALSA to OSS (why should it?) so people will keep complaining about cracks and pops and out-of-the-box hardware support, and new bugs will inevitably crawl in during the process of converting existing drivers from ALSA to OSS.
Of course, developers will have to support ALSA for a long time (dropping ALSA altogether would break nearly ALL the current linux applications, not just flash player) so the support burden for distributions maintainers would become even heavier.
All of this - because ALSA does not match the pipe dream about sound systems of TFA writer. In the end, the features offered to the end user by a OSSv4 stack would be less than those provided by a working ALSA + PulseAudio stack, as even the writer itself states (about hybernation support).
Not to mention the fact that nowadays many applications will make use of high level libraries that hide the details of the sound system from them, so they couldn’t care less about ALSA or OSS.
So no, thank you! Please report bugs, do complain as loud as you can, but yet another fork is the last thing we need now.
incorrect. The proprietry nvidia drivers are not even installed by default, and never have been. There was talk about providing them out of the box but it never eventuated. They are, however, easily installable via the "hardware drivers" app.
being vague is almost as cool as doing that other thing...
vlc has options to change the way output is handled, try them, maybe you can find out more about what the problem is.
New things are always on the horizon
OSS. It's standard on all UNIX-like systems except OS X. The API is painfully simple. There are no libraries, the only dependency is a single header (soundcard.h). To play sound, you open() /dev/dsp and write() the data there. If you want to change the format (e.g. sample size, rate, or number of channels), then you issue an ioctl().
If you use FreeBSD, then you've had in-kernel sound mixing with OSS since around 2001. It was a bit difficult to use back then; you got a different device for each channel and had to configure each app to use a different one (I had one for each of KDE and GNOME's sound daemons, one for xmms, and one for games, for example). With FreeBSD 5 (January 2003), each app to open /dev/dsp got a new vchannel, so all sound-outputting apps got a trivial-to-use interface that supported mixing.
Now, both OpenSolaris and FreeBSD support the newer OSS API, which is backwards compatible but also provides per-channel volume controls and a few other nice things. Linux does if you install the 4Front OSS implementation (which the author of TFA is recommending), but by default ships with ALSA, which is a Linux-only API that is not backwards-compatible with OSS (which was the standard Linux sound API until ALSA shipped).
It amuses me that I've had multiple applications able to play sound on a cheap soundcard, using a simple, well-supported, API on FreeBSD for almost a decade, and yet people still claim Linux is ready for the desktop but FreeBSD isn't.
I am TheRaven on Soylent News
Well, of course. 3D acceleration on Linux requires in-kernel drivers, and the kernel interface changes constantly, so the drivers need to be constantly updated to work with new kernels. Open-source drivers would solve the problem, but manufacturers don't want to provide them and Linux isn't anywhere big enough to force them to. The end result is a nightmare; for example, I can't update the kernel because the last drivers that work with my card (Geforce 2 MX) don't work with the new kernel. And while I got an old Radeon for free, it won't work with my motherboard (KT7A).
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
If Ubuntu sees it has a video card which the proprietary Nvidia drivers are available for, then it will prompt the user to permit it to download and install the drivers itself. It doesn't have the drivers installed by default.