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
No, because you do not have to use Pulseaudio.
He says pulse sucks for games . Although he is exaggerating the latencies, I can believe it.
It is so, so for video (you can get occasional lack of sync)
It does audio very nicely - mixing works fine, you can play different streams to different cards (yes, I do that), you can play streams on remote servers, you can combine all local sound cards into a single virtual device etc.
So the problem is not that we do not have good solutions. It is that we have different solutions with different strengths and it is not clear which should be the default. He thinks pulse should not be the default. I like pulse although I would like the latency and reliabliity issues dealt with.
I have 7 Internet-connected personal machines at the house (7 Linux boxes, 1 Wintendo), and one Linux laptop is connected to a 5.1 surround system in the office.
Every machine on the network (with the exception of the Wintendo) can play audio over the network through the 5.1 surround system via Pulseaudio, with no appreciable loss of sound quality.
I can sit on the couch with a wireless-enabled laptop and play music from the headless file storage machine through the 5.1 surround system remotely.
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...
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".
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.
I tried Ubuntu studio on several different machines, and had no luck at all. If you try Pro Tools on the Mac, I'm sure you'll see what I'm talking about. The quality of sound is 100%, and using multiple sound sources not only works, it *just* works.
That was not my experience with Ubuntu studio (nor Gentoo, Debian, dyne:bolic, arch, crux). I found them really wretched to work with, if you can even get them to work. Multiple sound sources via jackd? No way, it just doesn't work. Also, the sound quality matters a lot to me, and with alsa it's terrible. I've been trying to do what I do in Linux since 2003. It still isn't ready.
I truly hope it will be one day soon...
by Anonymous Coward
on Friday June 19, @06:19PM (#28397301)
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.
I HIGHLY agree with this. I thought audio production was at a complete standstill in the days of Rosegarden since it crashed for no reason on any machine I installed it on. It was a great concept, but it simply didn't work. When I installed Ardour I couldn't believe how great and functional it was. The ubuntustudio package is indeed a super easy way to get yourself up and running. Not to mention there is a pretty big following in #ardour on Freenode. Always someone there willing to lend a hand. Beats spendi
I'm with you. I've been using Ardour [ardour.org] and Hydrogen [hydrogen-music.org] for years. Also use Rosegarden [rosegardenmusic.com] for keyboard synth. My keyboard is a M-Audio 49-key USB interface, just plug it in and go. I've set up a few audio production systems for friends as well. Shane Bertrand [myspace.com] has been recording and mixing his own music on one for 5 years now. A 10 input M-Audio Delta 1010LT [m-audio.com] sound card, Ardour, and Hydrogen are his main tools. They recorded and produced both CWO [myspace.com] albums on this setup. They used 5 mics to record the drummer; Shane's modest system had no problems handling it all, even at more than 40 tracks in a song. He had a Sempron 2500+ and 512MB RAM w/ Kubuntu, just upgraded to a X2 3800, 2GB RAM a few months ago.
All FUD. The fact you are using Gentoo and having problems is probably half your problem. The tools you choose to use are NOT the fault of GNU/Linux- they are your own. Apple and Microsoft by your own evaluation would be just as bad or maybe even worse!
You know, when i read moronic bullshit like that I sometimes wonder for a moment why don't I just stick with OS X. Why should I spend endless hours every other month or so trying to get a satisfactory result out of various Linux distros, anyway? Then I remember, I love Linux in spite of assholes like you. And I hope one day to be able to say with pride, "I recorded, mixed, and mastered this project all in Linux, using nothing but FOSS!". And when that day arrives, it will be in spite of, not because of, idiots like you. Burying your head in the sand may make you feel better in the short term, but it doesn't get the work done.
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?
So again, what was Linux hoping to achieve by dropping old "obsolete" OSS in favor of increasingly complex solutions?
As far as Ubuntu is concerned, its the same inane neophyte behavior that "obsoleted" Xmms and BMPx in Jaunty in favor of the iTunes wannabe Amarok, which I find much less stable and cumbersome to use. There was absolutely nothing wrong with Xmms as a Winamp-style media player that was quick, efficient and could handle Internet radio and almost all the popular DRM-free formats, yet it was automatically removed with other "obsolete" software. Yes, I can compile it again from source, but it just seems a bit obnoxious. BMPx was another simple media player that was quite nice, albeit with the occassional bug, and it too has been "obsoleted".
For all the evangelism of the Ubuntu community, why are we being driven towards solutions that mimic the proprietary soup-du-jour (iTunes in this case)?
There was absolutely nothing wrong with Xmms as a Winamp-style media player that was quick, efficient and could handle Internet radio and almost all the popular DRM-free formats, yet it was automatically removed with other "obsolete" software. Yes, I can compile it again from source, but it just seems a bit obnoxious.
Xmms is no longer maintained either, the developers have all moved on to Xmms2. So yeah, distro's don't include software that's been abandoned upstream.
"So again, what was Linux hoping to achieve by dropping old "obsolete" OSS in favor of increasingly complex solutions?"
Linux deprecated OSS2, which everyone agrees sucks hard. It was a no-brainer.
OSS3 is significantly better but it was only recently open sourced. Frankly, if the OSS devs hadn't spent most of the last decade with their heads firmly wedged, audio on Linux would probably be in a much better state. Ah well.
Off by one. Linux deprecated OSS3, and OSS4 is now opensource.
And not only does it work better (in my admittedly little experience with it), it's also more in keeping with the UNIX philosophy of treating devices just like any other file. Sure, with ALSA you do have device files, but you pretty much have to use alsalib to use them AFAIK. With OSS, you get to use the standard UNIX file APIs.
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?
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?
Yeah, TFA explains it.. Here's it in short:/dev/dsp goes to kernelspace, while ALSA does mixing in userspace. I've no idea how difficult it would be to make ALSA do sound mixing in kernelspace.
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?
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."
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.
If you bothered to try, you'd find that it does.
See the dmix page [opensrc.org], 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.
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!
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.
by Anonymous Coward
on Friday June 19, @05:13PM (#28396607)
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.
If instead the effort had been applied to fixing OSS, sound on Linux would now be further ahead than it is now.
You hear this a lot in the open source circle. Many projects have close competition (Gecko/KHTML, KDE/Gnome, etc.) where this comment might apply. The problem is that "fixing the few issues that existed" is frequently not only very hard, but also very boring. Put another way, if it was fun and/or easy, the original developers would've already done it. IOW, this is probably crappy work that you have to pay people to do, and unfortunately free software doesn't usually pay, so volunteers gravitate towards the fun and easy (at least, perceived to be easy), which is often to start a new exciting project.
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.
I agree with the specification point, and agree that the lowest level API should be as basic (and standard) as possible. Then, once you have that, you can layer whatever higher-level architecture you like on top, as the low-level drivers are "just there" and will "just work".
However, this doesn't help applications, necessarily. I would argue to help apps writers, you need to standardize the glue between layers, such that sound and commands can be passed from one layer to another in a predictable manner. Innovators can always add new commands that are parsed by their own injectable layer.
I would also argue that it's impossible to chain userland software a-la JACK via the kernel efficiently, as you've a double context switch per element in the chain. Since transforms are CPU intensive, you want to do the fewest composite transforms possible, which means a software mixer should be something you can chain, which means that the heavy-lifting mixer needs to be in userspace.
(Either that, or you're going to need LADSPA and LV2 support in the kernel, plus some way of coaxing "smart" sound cards into supporting such effects. Since the kernel developers would force the first coder who tried to submit such a patch to walk the plank, I don't see it as likely.)
This would leave the low-level mixer for mixing between kernel threads (rather than between applications per-se) and normalizing the inputs. If we're not having to normalize values anywhere else in the process, we should end up with improved quality and less latency. (Anything that mucks with precision hurts quality, and any operation at all hurts latency.)
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 [ubuntuforums.org] my best attempt to characterize the bug: Here's [launchpad.net] a bug on launchpad that may or may not be the same thing:
... 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
The Linux and Slashdot communities are certainly not police states but sometimes they do degenerate in to "mob rule". In "mob rule" the people who excel at shouting others down and pandering to what the mob wants to hear often win even if they are wrong. I've excelled at it myself here sometimes:)
I'm not sure if the problem is even in any of the the actual fracking articles no one reads, but more the trollish way things were worded in the submission to Slashdot, which seems designed to provoke a fight. The submission seems crafted to make Adobe look evil and bad, Linux look good, for no actual reason other than its certain to be red meat to the slashdot mob and sure to win acceptance with the/. editors. I hate Adobe and Flash as much as the next guy, maybe more, but from what I read in the blog of the Adobe Linux guy he seems to be a pretty decent guy trying to make good on a tough situation.
IMHO, and it appears in the opinion of many others posting tonight, audio on Linux is deeply messed up, and its a leading factor in killing Linux acceptance on the desktop. Linus or other Linux kernel leaders seriously need to step up, lead a rational discussion of the problem, throw out all the old biases and misconceptions and come up with a rational fix. Audio on Linux has been bad for 10 years, its not getting any better and ALSA is more the problem than the solution, as are all the hacks like pulse, esd, arts, gstreamer, etc.
Audio more than any other issue turned me and several others I've read tonight from Linux to Mac for our desktop, and I've been a Linux fan and desktop user for a long time as you can tell from my 5 digit/. user ID so it wasn't a switch I made lightly.
The original submission makes it sound like audio on Linux is great and its only a bunch of whiners and evil corporations spreading FUD about Linux saying otherwise, which is pure mob rule pandering.
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...
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.
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?
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.
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...
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?
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.
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).
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.
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.
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...
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.
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.
By saying that he proves his former point (Score:4, Insightful)
Re:By saying that he proves his former point (Score:5, Insightful)
If Pulse Audio really sucks, then Linux Audio really is in a sorry state
No, because you do not have to use Pulseaudio.
He says pulse sucks for games . Although he is exaggerating the latencies, I can believe it.
It is so, so for video (you can get occasional lack of sync)
It does audio very nicely - mixing works fine, you can play different streams to different cards (yes, I do that), you can play streams on remote servers, you can combine all local sound cards into a single virtual device etc.
So the problem is not that we do not have good solutions. It is that we have different solutions with different strengths and it is not clear which should be the default. He thinks pulse should not be the default. I like pulse although I would like the latency and reliabliity issues dealt with.
Parent
Re:By saying that he proves his former point (Score:5, Informative)
Pulseaudio rocks IMO.
I have 7 Internet-connected personal machines at the house (7 Linux boxes, 1 Wintendo), and one Linux laptop is connected to a 5.1 surround system in the office.
Every machine on the network (with the exception of the Wintendo) can play audio over the network through the 5.1 surround system via Pulseaudio, with no appreciable loss of sound quality.
I can sit on the couch with a wireless-enabled laptop and play music from the headless file storage machine through the 5.1 surround system remotely.
We've come a long way, baby.
Parent
Re:By saying that he proves his former point (Score:5, Insightful)
Parent
Re:By saying that he proves his former point (Score:5, Interesting)
Which is great, but it's not so great if you are trying to produce audio.
When I plug my guitar in, I can notice a latency greater than 5ms. And greater than 25ms, it drives me insane.
Compare that to what I get with PluseAudio (usually): 100-150ms. No thank you.
Parent
Re:Pulseaudio sucks (Score:5, Funny)
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?
Parent
it's all relative (Score:5, Insightful)
Re:it's all relative (Score:5, Interesting)
Parent
Re:it's all relative (Score:5, Informative)
Parent
Re:10 Years From Now You'll Be Writing The Same Th (Score:5, Funny)
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"!
Parent
Re:10 Years From Now You'll Be Writing The Same Th (Score:5, Funny)
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.
Parent
Re: (Score:3, Interesting)
Re:it's all relative (Score:4, Informative)
Parent
Re:it's all relative (Score:5, Insightful)
You know, when i read moronic bullshit like that I sometimes wonder for a moment why don't I just stick with OS X. Why should I spend endless hours every other month or so trying to get a satisfactory result out of various Linux distros, anyway? Then I remember, I love Linux in spite of assholes like you. And I hope one day to be able to say with pride, "I recorded, mixed, and mastered this project all in Linux, using nothing but FOSS!". And when that day arrives, it will be in spite of, not because of, idiots like you. Burying your head in the sand may make you feel better in the short term, but it doesn't get the work done.
Parent
PulseAudio... (Score:5, Insightful)
What are we trying to achieve? (Score:5, Interesting)
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?
Re:What are we trying to achieve? (Score:5, Insightful)
So again, what was Linux hoping to achieve by dropping old "obsolete" OSS in favor of increasingly complex solutions?
As far as Ubuntu is concerned, its the same inane neophyte behavior that "obsoleted" Xmms and BMPx in Jaunty in favor of the iTunes wannabe Amarok, which I find much less stable and cumbersome to use. There was absolutely nothing wrong with Xmms as a Winamp-style media player that was quick, efficient and could handle Internet radio and almost all the popular DRM-free formats, yet it was automatically removed with other "obsolete" software. Yes, I can compile it again from source, but it just seems a bit obnoxious. BMPx was another simple media player that was quite nice, albeit with the occassional bug, and it too has been "obsoleted".
For all the evangelism of the Ubuntu community, why are we being driven towards solutions that mimic the proprietary soup-du-jour (iTunes in this case)?
Parent
Re:What are we trying to achieve? (Score:4, Informative)
There was absolutely nothing wrong with Xmms as a Winamp-style media player that was quick, efficient and could handle Internet radio and almost all the popular DRM-free formats, yet it was automatically removed with other "obsolete" software. Yes, I can compile it again from source, but it just seems a bit obnoxious.
You want Audacious [audacious-...player.org].
Parent
Re:What are we trying to achieve? (Score:5, Informative)
Xmms is no longer maintained either, the developers have all moved on to Xmms2. So yeah, distro's don't include software that's been abandoned upstream.
Parent
Re:What are we trying to achieve? (Score:5, Insightful)
"So again, what was Linux hoping to achieve by dropping old "obsolete" OSS in favor of increasingly complex solutions?"
Linux deprecated OSS2, which everyone agrees sucks hard. It was a no-brainer.
OSS3 is significantly better but it was only recently open sourced. Frankly, if the OSS devs hadn't spent most of the last decade with their heads firmly wedged, audio on Linux would probably be in a much better state. Ah well.
Parent
Re:What are we trying to achieve? (Score:5, Informative)
Off by one. Linux deprecated OSS3, and OSS4 is now opensource.
And not only does it work better (in my admittedly little experience with it), it's also more in keeping with the UNIX philosophy of treating devices just like any other file. Sure, with ALSA you do have device files, but you pretty much have to use alsalib to use them AFAIK. With OSS, you get to use the standard UNIX file APIs.
Parent
He makes one excellent and crucial point (Score:5, Interesting)
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?
Re:He makes one excellent and crucial point (Score:5, Informative)
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?
Yeah, TFA explains it.. Here's it in short: /dev/dsp goes to kernelspace, while ALSA does mixing in userspace. I've no idea how difficult it would be to make ALSA do sound mixing in kernelspace.
Parent
Re:He makes one excellent and crucial point (Score:5, Informative)
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.
Parent
Re:He makes one excellent and crucial point (Score:5, Informative)
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 [opensrc.org], 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.
Parent
Pulse Audio: the best gift the Linux world gave M$ (Score:5, Insightful)
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!
KISS (Score:4, Insightful)
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.
Parent
Re:Pulse Audio: the best gift the Linux world gave (Score:5, Informative)
The developer of PulseAudio explains some of the rationale in this interview [blogspot.com].
Parent
ALSA was a mistake (Score:4, Insightful)
Re:ALSA was a mistake (Score:5, Insightful)
You hear this a lot in the open source circle. Many projects have close competition (Gecko/KHTML, KDE/Gnome, etc.) where this comment might apply. The problem is that "fixing the few issues that existed" is frequently not only very hard, but also very boring. Put another way, if it was fun and/or easy, the original developers would've already done it. IOW, this is probably crappy work that you have to pay people to do, and unfortunately free software doesn't usually pay, so volunteers gravitate towards the fun and easy (at least, perceived to be easy), which is often to start a new exciting project.
Parent
The fundamental problem (Score:5, Insightful)
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.
Re:The fundamental problem (Score:5, Interesting)
I agree with the specification point, and agree that the lowest level API should be as basic (and standard) as possible. Then, once you have that, you can layer whatever higher-level architecture you like on top, as the low-level drivers are "just there" and will "just work".
However, this doesn't help applications, necessarily. I would argue to help apps writers, you need to standardize the glue between layers, such that sound and commands can be passed from one layer to another in a predictable manner. Innovators can always add new commands that are parsed by their own injectable layer.
I would also argue that it's impossible to chain userland software a-la JACK via the kernel efficiently, as you've a double context switch per element in the chain. Since transforms are CPU intensive, you want to do the fewest composite transforms possible, which means a software mixer should be something you can chain, which means that the heavy-lifting mixer needs to be in userspace.
(Either that, or you're going to need LADSPA and LV2 support in the kernel, plus some way of coaxing "smart" sound cards into supporting such effects. Since the kernel developers would force the first coder who tried to submit such a patch to walk the plank, I don't see it as likely.)
This would leave the low-level mixer for mixing between kernel threads (rather than between applications per-se) and normalizing the inputs. If we're not having to normalize values anywhere else in the process, we should end up with improved quality and less latency. (Anything that mucks with precision hurts quality, and any operation at all hurts latency.)
Parent
Fud? Er, no... (Score:4, Informative)
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.
kernel is fine, distros have problems (Score:3, Insightful)
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 [ubuntuforums.org] my best attempt to characterize the bug: Here's [launchpad.net] a bug on launchpad that may or may not be the same thing:
A sure road to success ..... (Score:5, Insightful)
... 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
Re:A sure road to success ..... (Score:5, Insightful)
"This is not a police state"
The Linux and Slashdot communities are certainly not police states but sometimes they do degenerate in to "mob rule". In "mob rule" the people who excel at shouting others down and pandering to what the mob wants to hear often win even if they are wrong. I've excelled at it myself here sometimes :)
I'm not sure if the problem is even in any of the the actual fracking articles no one reads, but more the trollish way things were worded in the submission to Slashdot, which seems designed to provoke a fight. The submission seems crafted to make Adobe look evil and bad, Linux look good, for no actual reason other than its certain to be red meat to the slashdot mob and sure to win acceptance with the /. editors. I hate Adobe and Flash as much as the next guy, maybe more, but from what I read in the blog of the Adobe Linux guy he seems to be a pretty decent guy trying to make good on a tough situation.
IMHO, and it appears in the opinion of many others posting tonight, audio on Linux is deeply messed up, and its a leading factor in killing Linux acceptance on the desktop. Linus or other Linux kernel leaders seriously need to step up, lead a rational discussion of the problem, throw out all the old biases and misconceptions and come up with a rational fix. Audio on Linux has been bad for 10 years, its not getting any better and ALSA is more the problem than the solution, as are all the hacks like pulse, esd, arts, gstreamer, etc.
Audio more than any other issue turned me and several others I've read tonight from Linux to Mac for our desktop, and I've been a Linux fan and desktop user for a long time as you can tell from my 5 digit /. user ID so it wasn't a switch I made lightly.
The original submission makes it sound like audio on Linux is great and its only a bunch of whiners and evil corporations spreading FUD about Linux saying otherwise, which is pure mob rule pandering.
Parent
Developer FAIL (Score:5, Insightful)
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...
PulseAudio (Score:5, Insightful)
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.
Are you kidding? (Score:5, Interesting)
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?
Someone please fork OSS4 (Score:4, Insightful)
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.
Re:State Of Linux Pretty Fucking Sorry After All (Score:4, Funny)
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
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?
Re:Main blocker (Score:4, Insightful)
Parent
Re:Main blocker (Score:4, Interesting)
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 [phoronix.com]
Parent
Re:Main blocker (Score:4, Insightful)
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.
Parent
Re:Main blocker (Score:5, Insightful)
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.
Parent
Re:Main blocker (Score:5, Funny)
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...
Parent
Re:Main blocker (Score:5, Informative)
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.
Parent
Re:Problem with PulseAudio? (Score:5, Interesting)
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.
Parent