Submitted by Linux.FR has an interview with Lennart Poettering of PulseAudio and systemd fame (among others). Regarding PulseAudio: “I can understand why people were upset, but quite frankly we didn’t really have another option than to push it into the distributions when we did. While PulseAudio certainly wasn’t bug-free when the distributions picked it up the majority of issues were actually not in PulseAudio itself but simply in the audio drivers. PulseAudio’s timer-based scheduling requires correct timing information supplied by the audio driver, and back then the drivers weren’t really providing that. And that not because the drivers were really broken, but more because the hardware was, and the drivers just lacked the right set of work-arounds, quirks and fixes to compensate for it.”
I guess I’ve always been luck with Audio support in linux. My Trigem Gemstar worked back with audio back in 1998. My brother’s pc had crappy windows audio drivers that we never got working: Pulse audio worked like a charm.
Granted I don’t know the details, but if the drivers and hardware work under other operating systems and earlier linux distros, then one has to ask why pulse audio broke things.
I’ve seen many problems go away when pulse audio was uninstalled. From a user perspective, and even as a dev, my instinct is to say pulseaudio was at fault. Maybe they are feature limited in some way, but it bothers me greatly to use that as an excuse for breaking audio under many linux distros.
Pulseaudio uses code paths that implement advanced functionality; these code paths had never been tested in many drivers because most people didn’t use them and nobody cared about it. Pulseaudio forced maintainers to implement correctly all the advanced stuff. If Linux had more people working on the audio stack maybe those bugs could have been fixed sooner, but we don’t have that luxury.
The criticism to Pulseaudio is getting ridiculous. Nobody knows the name of the people that actually had bugs in their drivers, but everybody hates Lennart for exposing them? What is next, should we hate the ACID tests because they expose bugs in IE?
Edited 2011-07-07 20:18 UTC
Ah, the hypocrisy.
People defending PusleAudio because it “exposed bugs in the drivers” and was sorely needed to advance the Linux audio stack, yet lambasting KDE4 for doing the same to the graphics stack.
(Not saying you are doing that.)
I imagine there are some…
But I suspect that in the majority there is a significant overlap in the two groups…
Anybody that hates Poettering for that needs to have his head examined. It ain’t that serious.
I do think the interview showed a good deal of arrogance on Poettering’s part, for example when he says (when asked about the BSDs continuing to use OSS instead of ALSA or PA:
He doesn’t explain it except to say
Never mind that I use OpenBSD as my desktop and my only real audio need is to listen to my music, which I do quite easily. Never mind that I never need to “handle more than one client with different latency constraints” and that I’ve never done mixing or sample conversion. Never mind that it’s a very very small subset of the people who use Linux who need to do those things anyway.
I’m not annoyed at him exposing bugs or implementing what could well be a better way overall. On the contrary, those are good things. I’m annoyed at his insistence that something which fills all my needs (even if it doesn’t fill absolutely everyone’s) is wrong and must be replaced by a much buggier stack that is—in execution if not design—less functional.
When you have a 5.1 stream and you want it in a 2.0/2.1 system you need to mix the channels. These days that is quite normal. Also in portable systems to save power and not wake the system as often you want very high latency audio which you cannot do with alsa or oss. As far as I’m aware WebOS, Maemo and meego all use pulseaudio versus raw alsa for this very reason
Ah, but is that because Pulse is so much better than everything else (OSSv3, OSSv4, FreeBSD OSS, OpenBSD sound, etc)? Or just because ALSA sucks so horribly?
The fact that projects use Pulse over raw ALSA just shows how bad raw ALSA is; it has no reflection whatsoever on any other audio stacks.
With the exception of Bluetooth audio, everything you can do with Pulse, I can do on FreeBSD using “that poor pathetic OSSv3”, including all the different mixing of channels, redirecting of the network, multiple soundcards, multiple sources, etc.
Oss does not do high latency audio or timer based audio. So every sound is data transfer operation happens synchronously. So if you have a 10 min audio stream the bus stays active for the entire 10 minutes. With pulse it is upload chunk, then sleep some time then upload another etc…
see this, it explains it far better and more completely:
http://0pointer.de/blog/projects/pulse-glitch-free.html
Edited 2011-07-07 21:43 UTC
_txf_,
Thank you for the link, definately informative. However it seems to contradict Lennart’s recent statements in a few places. Particularly:
“We become much less dependant on what the sound hardware provides us with. We can configure wakeup times that are independant from the fragment settings that the hardware actually supports.”
From your link, the main difference from traditional audio processing is that “pulse audio glitch-free” opts not to use sound card timers/IRQs and use system timers/IRQs instead to provide even lower latency than is available through the sound card. Pulse audio can therefor update the DMA buffer at any time without synching with the sound card timer.
This is great (no sarcasm), but I don’t get why he claims a break in compatibility was necessary. What technical reason is there that pulse audio could not revert to sound card IRQs instead of breaking things? In the absolute worst case, this would have resulted in higher latency, which is at most a minor annoyance.
I’m not understanding the technical reason that pulse audio couldn’t revert to using sound card IRQs as they were intended instead of breaking sound support all together? Can someone clear this up?
From my understanding the goal here is generally the opposite (to allow application that are not affected by latency to provide sound output at the highest latency possible yet have the flexibility for low latency).
The thing is that using the sound card irqs would result in generating an interrupt for every fragment of sound that is sent to the soundcard.
The fragment size is fixed by the soundcard and not the system, hence not dynamically reconfigurable. Also note that the soundcard has no information on the system and as such cannot make any judgements on the best solutions.
_txf,
“From my understanding the goal here is generally the opposite (to allow application that are not affected by latency to provide sound output at the highest latency possible yet have the flexibility for low latency).”
Yes I understand that.
“The thing is that using the sound card irqs would result in generating an interrupt for every fragment of sound that is sent to the soundcard.”
Yes, but so what? He says himself this IRQ interval is adjustable. Besides, isn’t it a little silly to claim that cutting out the sound card IRQs is beneficial when you end up resorting to increasing the system irqs by an order of magnitude? (He admits this in the link).
“The fragment size is fixed by the soundcard and not the system, hence not dynamically reconfigurable. Also note that the soundcard has no information on the system and as such cannot make any judgements on the best solutions.”
It was a very long time ago, but I did some sound card programming in Dos/W98 days and I can say that sound cards would accept any DMA size you programmed them with. I’m not sure about the fragment size, but I always just used two.
The two objections which Lennart has with this (working) model seems to be latency and audible clicks when changing sound card parameters dynamically. This is totally plausible. However, these are minor quibbles for most users who just want the audio to work. Pro users who want better audio can always buy a better sound card.
I totally “get” the benefits of switching to a zero-latency model. To be sure, it is worth having. But why was pulseaudio built with all or nothing support? Where is the technical reason pulse audio could not have been programmed to optionally run off of sound card IRQs at the expense of latency?
There would have been no negative for existing users who were already content with their audio latency/power consumption/IRQ rate/etc.
Probably no real reason other than the authors vision and the lack of desire to add complexity to the code. Of course other kinds of complexity have been added (like network transparency etc) so I don’t know how valid the second point is.
I also suspect that because pulse is meant to be “the” single userspace api (outside of jack for pro audio) they didn’t want its functionality to diverge from the primary form. Also If people wanted that they could just stick with alsa and dmix…
_txf_,
Yea, this ordeal is mostly behind us. However I am afraid of the consequences of what happens if we routinely adopt the notion that progress implies breakages. Sometimes it may be the case, but it needs to be managed very carefully.
Sure, this one is over but the systemd ordeal is looming at the horizon. Same “It’s my way or the highway and screw anyone who thinks different” approach.
Works for me, thankyouverymuch…
That’s a fair point, I admit. Still, the most readily available source for 5.1 streams for most people would be DVDs, right? Is it still technically illegal to watch DVDs under anything other than Windows or OS X? (I’m asking; I just don’t know. I’ve always preferred watching DVDs on a TV, so I’ve never messed with that.) Assuming it is legal under Linux, I’d have no problem with apt-get install dvdplayerapp pulling in PA as a dependency—my issue was just with Poettering basically saying “You are wrong” to people whose setups were clearly working for them.
And it makes perfect sense for them to do so, because what they need can’t be supplied any other way. But they’re not a normal desktop case.
I beg to differ. As laptops start to eat desktop’s lunch more and more, battery life could well end up being a major “desktop” concern.
Then of course, optimizing the power consumption of something as light as audio streams while adding at the same time highly power-intensive GPU effects to the graphical stack is probably a bit hypocritical, but well…
diegocg,
“The criticism to Pulseaudio is getting ridiculous.”
It’s apparent from the voting that your opinion is more popular here, but I really don’t think it’s ridiculous to criticize pulseaudio (and the distros loading it) when the result was many broken systems.
Personally I am obviously still a devoted Linux user, but these things should not happen with a professional OS. Even if the changes were ultimately beneficial, the chaotic process through which pulse audio was released is unfortunately a set back to the credibility of a reliable OS. It is exactly this sort of mismanagement that fuels the cry that linux is not ready for the desktop.
Personally I am obviously still a devoted Linux user, but these things should not happen with a professional OS. Even if the changes were ultimately beneficial, the chaotic process through which pulse audio was released is unfortunately a set back to the credibility of a reliable OS. It is exactly this sort of mismanagement that fuels the cry that linux is not ready for the desktop.
< elitist ass > It separates the men from the boys. < /elitist ass >
For me the part in bold is what counts. Progress is painful. I’ve been using Linux since 1998 and there have been bumpy rides, but the system always got better, even after a temporary regression.
It is in the nature of people to bitch and moan about temporary setbacks. Look at the abuse we all gave MS over Vista. Now that Vista has been thoroughly polished and re-released as Windows 7, where are the cries now? Not to be heard. Yet vista was necessary to get to Windows 7. (Yes, a Linux user can praise MS…)
If you can’t be on the bleeding edge, curb your updateritis and stick with a long time support release without the problematic feature. There are enough enthusiasts out there to iron out the kinks, before anyone needs to get near a new, bleeding edge feature.
Linux at least has the luxury of a few bazzilion distro’s, so there should always be one with the right feature set. MS didn’t have that luxury with Vista.
r_a_trip,
“For me the part in bold is what counts. Progress is painful. I’ve been using Linux since 1998 and there have been bumpy rides, but the system always got better, even after a temporary regression.”
But I strongly disagree with the notion that progress has to be painful. There was no technical reason in this case to make it so painful.
If a for-profit (non-monopoly) company were to do this regularly with it’s product lines, then it would likely have irate customers who would be inclined to do business elsewhere. I would add that the company even deserves to loose business.
I’d seriously like to know why linux is different? (yes, I know it’s free).
“It is in the nature of people to bitch and moan about temporary setbacks. Look at the abuse we all gave MS over Vista. … Yet vista was necessary to get to Windows 7. (Yes, a Linux user can praise MS…)”
Wow, I’m astonished to hear this. If microsoft wasn’t a monopoly with strong staying power, this would have put it out of business. Vista was not ready, and microsoft deserved all the criticism it received.
“If you can’t be on the bleeding edge…”
The problem isn’t with the bleeding edge in my opinion, it’s that compatibility with the existing model was almost deliberately broken.
I find statements like these to be quite pointless, I remember tons of complaints over broken video/audio drivers as Microsoft released Vista with it’s new driver architectures, and Microsoft have alot more resources at their disposal for testing before release than Linux devs have.
For OSX obviously it’s a different matter since they control the exact hardware and thus only have to make it work flawlessly against their particular specification. So I’m guessing they are the only ones that would get your ‘professional OS’ seal of quality.
A brief web search shows that OSX with the limited Apple hardware has more than its share of audio problems:
http://forums.cnet.com/mac-forums/mac-os-x-forum/1770-5_102-0-2.htm…
http://reviews.cnet.com/8301-13727_7-20075185-263/workaround-for-au…
http://www.macobserver.com/tmo/article/Mac_OS_X_10.4.10_Audio_Probl…
http://support.apple.com/kb/HT2178
When will we dispense with the delusional “Macs just work because all of the hardware is theirs” mentality. Apple products never “just worked.”
Well, I have no first-hand experience at all with OSX and as such I assumed that since Apple have total control of the hardware in their products it would be very strange if the limited hardware they do support would have less than stellar drivers.
Silly me from the sound of it
You shouldn’t hate the ACID tests…
but imagine if the Google made their homepage make use of advanced HTML features requiring 100% ACID pass rate. Suddenly 90% of the world can’t access Google when they previously could?
That would create a huge storm as well.
At the end of the day you make your products for your users. Google would never do that to it’s users.
Neither should Linux distros.
The fault lies with the distros for packaging pulse audio when a lot of audio drivers didn’t implements advanced functionality 100%.
That’s the general problem with Linux distribution model which puts all the burden of integration testing on distributors . This obviously blurs responsibility of respective components maintainers giving way to demonstrated responsibility shifting between teams working on different layers.
In closed environments making sure hardware works is a sole responsibility of the driver creator, who in turn can count on assuming relatively stable set of HW/driver interactions secured by stable OS middleware. In linux the middleware/ driver api is in constant flux. That invalidates any testing efforts between even minor releases.
Integrating those pieces into relatively stable coherent whole across wide range of HW/SW combinations (as required by desktop linux) is mission impossible.
That’s (among others) why Linux have failed there while it thrives in more controlled environments (phones, appliances, servers, etc.) where testing is at least manageable.
I’d disagree, in this particular case. There hasn’t really been any kind of API instability for audio on Linux. PA is built on ALSA, and ALSA’s API hasn’t changed in years and years.
The major problem with Linux audio is very simple and is called out by Lennart in the interview: there just aren’t enough people working on it. As Lennart says, there’s about three and a half people trying to do the entirety of all audio work on Linux, including improving PA and ALSA, fixing bugs, *and* supporting new sound hardware. That’s not close to enough.
True, but on the other hand variety of sound hw decreases as PC sound is being commoditized around MOBO integrated chips. Fewer and fewer users bother to buy a discrete sound card on their PCs.
New sound hardware, like USB, Bluetooth, and uPnP, are not integrated chips.
So, basically, he says it was everybody’s fault except his.
From that alone, in the summary no-less, he doesn’t try to avoid blame. He simply points out that PulseAudio was using features that drivers advertised but which didn’t actually work properly.
I changed your bolding to better reflect how I read it. He says, essentially, “Yeah, we had some bugs, but it was really the drivers and hardware’s fault.” Never mind that PA broke existing working configurations. I’ll grant that he did accept some blame, but he pushed a big honking lot of it onto everyone else.
I say that it’s completely wrong to blame Lennart. He has done a fantastic job!
Blame the distros for making it the default prematurely, not integrating it properly and worst of all, not making the default config of most programs in the repositories use it properly.
That’s pretty much LP’s view on everything. Whenever there is a problem with one of his projects or compatibility issues come up it’s always everyone else’s fault.
He says it was a driver issue, no, wait, it’s a hardware issue. Well if it was a hardware issue then why did audio work fine under other operating systems using the same hardware? If it was a driver issue, then why did ALSA work so well on systems where Pulse refused to function?
The fact was PulsAudio was broken on arrival and it took a long time for it to get sorted out, probably because the developer was in such denial.
That’s a very ignorant and unfair claim. If you look at the ALSA changlogs for the last years you will see that Lennart has committed a MASSIVE amount of bugfixes for ALSA drivers himself!
Also take a look at some audio driver source code sometime. The workarounds needed to make some hardware work are agonizing at times.
The manufactures provide Windows-drivers already complete with workarounds for hardware bugs but just because the bugs normally (when using Windows) aren’t exposed to the end user doesn’t mean that the hardware isn’t buggy.
The FOSS world doesn’t usually have the luxury of manufacturer support. Things like this are found by trial-and-error by committed people like Lennart.
Sigh. It has been explained many times. That is because pulse uses the soundcard in a different manner than plain alsa. Also note that there was hardware that failed to work in vista due to the new sound model (similar model to pulse and coreaudio).
The logical thing to do when faced with that is to fix ALSA or accept that using ALSA was wrong. Retro-fitting another userspace layer over the top and trying to justify it is the wrong choice.
I take it Pulse still isn’t a system service?
why don’t you get on that and then we can choose…
The point being that he was the only one that did anything about it. As nobody else stepped up to the table and provided alternatives then that is what we are stuck with whether it is good or bad.
He obviously believes that is the way to go and he got a lot of criticism for it, but that is all he got. Nobody else offered to help or attempted an alternative.
I would point out that plenty of other sound stacks run in userspace…
Edited 2011-07-09 17:00 UTC
That’s Lennart for you. He’s doing the same thing now with systemd.
In the interview, Lennart says:
Why? I mean, seriously, why? All I want is my computer to play my audio files, and maybe do a nice beep at me when it pops up an error dialogue. I know there are people who want all the sophisticated audio capabilities, but the vast majority, I think, don’t. Let the people that want that kind of thing get it elsewhere instead of breaking everybody’s sound with PulseAudio. Pushing PA on everybody really struck me as forcing the “right way” over the “way that actually works.” It’s exactly this kind of overly frequent reimplementation for no gain to most users—quite the opposite—that drove me away from Linux.
Well, yes and no. In the short term you’ve got a point; and in the longer view there is a point where it has to be engineered right to be capable across a range of applications.
Frankly whenever and whoever took the bull by the horns saying, in effect: “now is the moment” to sort out the sound sub-system … would be unpopular for a while.
He makes the same point himself:
As with many areas of life: there are good and honourable ways to proceed that just don’t get the job done.
The struggle is to find ways to proceed that do get the job done; and are honourable and good.
Well, yes and no. In the short term you’ve got a point; and in the longer view there is a point where it has to be engineered right to be capable across a range of applications. [/q]
Again: why? Or put better, why are these mutually exclusive? Keep the old way as the default, but offer the new way as an option until the kinks get worked out—lots of distributions used this strategy for the ext2–ext3 transition, I seem to recall.
Sure, I’ll buy that. But I think it’s beside the point.
Essentially his argument is “We had to push our buggy software on people because, since not enough people are interested in testing it, we have to make them.” Does no one else see the enormous problems with that? Not least that if manpower is really that much of a problem for you, maybe you should get the message that it’s not something people want or need?
Don’t get me wrong, I would have had absolutely no problem if PulseAudio had been optional, or if it had been part of a distribution specifically aimed at people who need its high-end features, even if it had been twice as buggy.
Because this is about drivers and hardware ? And we need people to test it and let’s be honest, a lot of the times in Linux you are the tester. It isn’t like in the Windows-world where the manufacturer will do all the testing with the platform.
I didn’t think Ubuntu was the right place, But Fedora was probably more appropriate.
Fedore seems to be more aimed at developers and Ubuntu at ‘normal users’ (whatever that means).
Edited 2011-07-07 21:04 UTC
I don’t think this is a good argument.
Existing users don’t know what they need.
Also, if you think long term, what about the would-be users?
How many people don’t use Linux because of lack of games?
How many game developers don’t have a Linux port because of crappy audio stack?
Maybe not, but they know what they want. And apparently only 3.5 people (according to the article) want a “modern” audio stack enough to work on it. I’m not saying that that’s a good thing, or good for Linux long-term; I’m just saying that it’s the way even Poettering admits things are now. I’m glad that those people who need it can use PA to do fancy audio things. I just think that the people who need that are the minority.
I think this is one of those cases where contradictory things are both true, and you have to balance them.
Why? I mean, seriously, why?
Glitch-free audio and reduced power consumption. These are not “sophisticated audio capabilities”, these are very basic requirements that a modern audio stack for desktops can’t miss and Linux was missing.
I’ll grant that glitch-free audio is a requirement for an audio stack, but every Linux box I ever used since ’98 had that, with OSS and then ALSA—to the extent of the majority of normal desktops need: like I said, to play some audio files and maybe a nice beep for an error. I don’t have any statistics, but I’d be very surprised if most people’s usage strays far from that.
I definitely do not grant that reduced power consumption is a “very basic requirement”—all else being equal, it would be nice to have that too. But I’d much rather have an audio stack without it that works than one that uses no power at all since it isn’t working.
Linux has had glitch free audio since 98? Really? Sure, the transition to PA was annoying as hell, but finally audio just works.
No more fighting the system to be able to have more than one application produce sound at a time.
No more stuttering when the system is under heavy load.
No more rebooting because a file handle didn’t get freed up correctly, effectively locking the sound card.
For me, there has historically only been one subsystem more annoying than sound, and that is X, but that got to the “i dont need to think about it” stage way before the audio stack did.
This was due to a fault in the OSSv3 support in Linux, and the half-bakedness of ALSA. All non-Linux Unix-like systems using OSSv3 have been able to mux multiple inputs into a single output.
Odd that people praise “yet another layer on top” for fixing this issue, when everyone else fixed it in OSSv3.
Will be interesting to see what happens in 2012 when “yet another layer” comes out to replace Pulse, instead of fixing ALSA itself.
Stop crying, just because you can play your mp3s on your 486 with 2-speakers doesn’t mean Linux audio need to get stuck.
There are people who have different needs than you have, and software must advance regardless of your needs or my needs.
I can’t stand Linux users sometimes, all they do is complain when someone actually wants to improve the system. It’s getting annoying and old.
So to answer your question of “Why”: It’s because people have different needs than you have, and they have the right to move the system forward. Quit being so bitchy and selfish, if you don’t like progress go use Windows 95.
Edited 2011-07-08 00:01 UTC
A. Grow up.
B. It’s not about not wanting things to improve. It’s about replacing a working system—albeit one that doesn’t do everything—with one that was in many cases broken, and then telling everybody it was The Right Thing To Do. I’ve got no objection to improvements, but they shouldn’t ever be the default until they by God work.
My guess is that every single former audio architecture dealt with CMOS/PIC/APIC timers and did just fine.
I can’t get why PulseAudio would want to mess with soundcard-specific timers while there’s tried and true support for several standard x86 timers in the Linux kernel. If there was such a thing as vertical synchronization problems on audio hardware (follow an arbitrary hardware clock rate to do some operations or face artifacts), I could understand, but to the best of my knowledge this is not the case.
Edited 2011-07-07 20:27 UTC
All the current (modern) audio stacks do it the same way Pulseaudio does (that is Vista+ and Coreaudio). I do recall many people with old soundcards complaining that sound was busted in Vista (I think it was some of the creative live and audigy cards).
I am so far from an expert that this is probably a worthless point but …
Soundcards have their own timers (mostly for sampling and audio output). Now, previously audio was done on a buffer basis along the lines of :
Cpu uploads sound output to soundcard buffer, buffer fills and sound is outputted per soundcard clock. It does this synchronously for a determined chunk size of the total sound output. So the bus is active for the entire period. Pulse, however waits for the longest period of time it possibly can and uploads it all in one go. Thus the system can sleep in much longer chunks hence saving power.
Edited 2011-07-07 21:28 UTC
Yep, I probably was tired when I read the sentence the first time, because I read it as “using (broken ?) sound card timer irqs” the first time, whereas now I read it as “using system timer irqs, using timer information provided by the sound card”.
I’d like to point out that they could do without the sound card’s timer information though, if it was broken, as long as they had sound card IRQ support :
1/Enable sound card IRQ
2/Measure sound care IRQ frequency using ultra high-resolution APIC timer (~.1 MHz audio clock vs an APIC clock that runs at hundreds of MHz = negligible aliasing)
3/Disable sound card IRQ and never enable it again
An ugly measurement is better than unreliable information
Edited 2011-07-08 10:00 UTC
I can’t say I’m actually familiar with the innards of any sound driver, much less PulseAudio specifically,
but I would guess that being able to sync to external MIDI clock may have been a design decider in this aspect.
It also seems like the generically more stable approach… i.e. across CPU architectures including distributed computing, etc.
So the guy thought it was a bad idea to have timing inside the kernel. DOES ANYBODY ACTUALLY DISAGREE WITH THAT?
Perhaps PA didn’t match ‘generalist’ needs at the time, but realistically, ‘desktop Linux’ with multimedia support wasn’t really all that big a market at the time. If it was a big market, the crappy drivers woulnd’t have persisted for as long as they have. So surprise, surprise, Linux audio stack developers are interested and focused on functionality useful for audio geeks, e.g. musicians. Is this really out of line for the general trend of Linux development?
Edited 2011-07-07 21:27 UTC
It seems that these topics are ignored by most except PA (and sometimes Lennart) haters. Because it works for most of people.
I call PA progress. Not to have to care about music player fighting with flash player just because the one likes to keep handle open (wasting power as well) is worthy. Yep, there is (was) dmix, but it also doesn’t work everywhere and in fact does something similar to PA’s job (and is a very cleverly made piece of software).
It was introduced early and therefore had bugs. This is normal in Linux. But it pays off. I don’t have to think about audio issues on linux anymore, it just works out of the box as in other major OS’s. For all that disagree, it is not mandatory.
Lets remember that Lennart did not have the power to force other distributions to adopt Pulseaudio. He was likely responsible for getting it pushed into Fedora; but Fedora is explicitly meant for such bleeding edge development. That other distributions picked it up around the same time suggests they too were convinced that the short term pain was worth the longer term gain.
Saying that you gave up “Linux” due to Pulseaudio shows more that you were using the wrong distribution for your needs than anything else.
http://tmrepository.com/trademarks/usedistrox/
Edited 2011-07-08 14:50 UTC
Quippy links aside, there are in fact distributions targeted at people who want conservative update policies, long term support, and to avoid bleeding edge software. There is no magic pixie dust or perfect distro. You have to understand the relevant trade offs, and make your choice. Abandoning Linux and going with another OS isn’t perfect either, just another set of trade offs.
However one of the most popular doesn’t, ubuntu were many people with Audio troubles that were “beta” testers, effectively while being sold something that according to the website is
One could say people should be using LTS … however … There is not even a mention of it on their homepage and is only accessible as a dropdown on the download page.
Edited 2011-07-09 09:51 UTC
OK, this is a presentation by someone who manages many Linux-desktops and is used to how things used to be in the Unix/Linux world.
Good or bad, things have changed in the last few years in most Linux distributions.
The presenter is trying to explain what is has become more complicated or isn’t even possible anymore with the new setup.
‘luckily’ Lennart Poettering was in the audience to ‘help’ explain why :
http://www.youtube.com/watch?v=_ERAXJj142o
The presentation is funny and sad at the same time. It shows you what he is like and what he thinks.
Lennart Poettering has vision of what thinks need to be improved for Linux on the desktop (possible server too). But he seems to always want to do big changes and not every idea always actually reaches it’s full potential.
His intensions are obviously good, but maybe he doesn’t work well with others as he doesn’t let others choose what they want. Like with systemd, where he has basically said: “the Linux API is the new Posix”
I’ve got a feeling Lennart Poettering will never be loved in the Linux community because of it.
Especially not by the BSD-community 😉
Edited 2011-07-07 22:17 UTC
He is hated by those who only play mp3’s on 10 years old hardware/speakers, and by the BSD community with their archaic system.
Those who use Linux on modern systems and do more things actually appreciate Poettering’s work.
I’m not sure why my comment got a score of 0, but I’m neutral.
I don’t think all users should have needed to deal with the problems of pulseaudio when it was still new. Why not start with Fedora first for example.
But I also think adopting the general ideas of systemd is really good.
Do we want Linux-only code ? hmm, again, maybe not so much.
I can speak for the BSD community here: we don’t have any hate for Poettering or for any linux developer. It’s already very difficult to set any standard in linux, so anyone that finds his way through deserves respect. I also personally appreciate his efforts to throw linux downhill ;-).
BSD is dying and ALSA is better than OSS, yeah sure… bla, bla, bla bla. Keep hearing that for years now, and it doesn’t change much: the BSDs seem immune to FUD.
You are the one spreading FUD here with that nonsense.
He isn’t throwing Linux downhill with pulseaudio (a sound server). In any case, he is developing for Linux, which is appreciated by many people.
Linux is evolving, BSD isn’t. This simple fact seems to bother the BSD people, that Linux gets most of the attention of developers and BSD doesn’t, now deal with it.
No, the BSD communities doesn’t care about him at all or what Linux does with it’s audio stack.
Sure, his “screw everyone who doesn’t write code for Linux” attitude is annoying but in reality he really doesn’t have all that much clout.
If BSD people doesn’t care about him or Linux why do they come and spread their FUD here?
Jealous much?
Edited 2011-07-08 23:51 UTC
You’re hilarious, especially with your “BSD is archaic” spiel. Who’s the one spreading FUD?
Maybe I shouldn’t have said that, in which case I apologize. But really, when was the last time we have seen any significant progress in the BSDs?
Every time I see a Linux release there’s tons of changes and progress, I haven’t seen something similar in BSDs.
There’s lot of progress but mainly not in the end-user desktop space.
It’s called stability and maturity. That said, there’s plenty of new stuff with, for example, each new OpenBSD release. Not exciting stuff like “we replaced the init system and now everything is wild, broken and crazy” but I can live without that in my infrastructure.
Edited 2011-07-09 02:14 UTC
It seems like we have to agree to disagree.
Linux isn’t any less stable or mature for having cutting edge init systems like systemd. In fact, I’m glad most of the innovation in this area and others are being done on Linux. Also, I believe this is one of the strong points of Linux, that you can choose whatever is best for you.
If you want rock solid init systems there is always sysvinit, runit, etc. If you want to play and experiment with new stuff there is systemd, etc.
I’m not saying BSD is bad, it has its place as other OSs, but Linux isn’t any less stable or mature for having different init systems, this is called choice, use the best tool for the job.
Trying to hide the fact that there isn’t any progress or innovation in BSD with “stability “stability and maturity” is just silly.
Edited 2011-07-09 23:28 UTC
Well, the one thing they do have is an API stable sound system that is there as a system interface and service through the whole system.
I am all for Linux distributions evolving, but pulseaudio was an example of attempting to fix a something that 99% percent of people do not use while crapping on something that 99% percent of people do.
Having said that, pulseaudio now works well (Alsa and dmix provided this for years without pulseaudio).
Edited 2011-07-08 20:29 UTC
Pulseaudio didn’t broke a damn thing, most of the problems were in ALSA. Pulseaudio exposed these issues and now that the drivers are fixed, everything works as it should. Get over it.
Edited 2011-07-09 00:28 UTC
I have got over it and now use pulseaudio.
But there is no use for constant denial.
Edited 2011-07-09 09:13 UTC
Sure, pulseaudio didn’t work fine before when it was firstly introduced, but it does work fine now. So who cares? just listen to your music and enjoy.
I can see both sides of the argument when it comes to Poettering. Although he seems to have what outwardly is a quite arrogant persona, I find myself agreeing with him more often than not.
PulseAudio ‘was’ a nightmare, these days it is pretty good in my opinion. I spent about 3-4 days just playing around with it and integrating it into my LFS system, and after that it worked perfectly for me – I don’t even have to think about sound issues now. I appreciate the work he and others have done to get it to this stage, and I am particularly impressed with the automatic ACL handling etc. by ConsoleKit – admittedly it required a recompile of udev in my case, but then I do make things hard for myself with LFS :-p
I appreciate that BSD and Solaris users are left out in the cold in terms of things like systemd, and I think the more operating systems the better, but as Lennart says – nothing is stopping them from porting it or reimplementing it, other than the large amount of work involved. A Linux user ‘can’ use it if they wish, or they can use systemV-init, upstart, or whatever works for them – no one is forcing them to use these modern elements.
That being the case, my only criticism of Lennart is his demeanour towards those of a different opinion.
I remember back in the day…early 2kish… I had to duel boot to Windows. Thing was, I could’nt play mp3’s and mute the video(exercise vid) at the same time. Per app audio volume management was a TRFM thing.
Anyways … I’m glad for the steady progress being made on all fronts. I usually wait 6 months or so before using this sort of stuff on my primary machines.
Using VM’s also helps to scratch the “latest and greatest” itch
go Lennart!!!!
ok first let’s see the person itself. he’s in the legue of Theo de Raadt, Dan Bernstein, Hans Reiser.
All those people who should be put in a small room and let them do whatever is needed to do on thecode. The communication should be done by people who are capable of doing so.
Secondly, while I understand that PA implementations may have surfaced problems inother code, this does not really mean that it’s a free tocket to f–k up things and say that it’s someone else’s fault. And that exactly is the reason why such peole should shut up in public as it does create a lot of harm.
People disagreeing on it, should again read the previous posts about it.
I have used OSS from Hannu when ALSA didn’t cut it. Always have seen hat his poduct worked better than ALSA and caused no problems at all.
Now, At some point ALSA was matue enough for my needs so left OSS for a while. And then PA came along.
Never ever I have seen such a piee of brokenness — that is being defended by people who don’t seem to care that stuff broke. Yes, progression is fine. Breaking things that for the most of people really works (the 99+%) is plain stupid and exactly describes how LP, HR, DB et al are — a bunh of people who may be brilliant developers but also hampered with that one hig more developers in generally seem to miss — teh ability to think outside their own small box.
Really that sucks. It also sucks that stuff broken. Luckily, Novell has systemd as a test available but keep init fo a while. They do understand that broken systems is not what people want.
And again, the video posted here above somewhere, exactly shows the way he is. And that really is a painful thing to see in he real world. I would definitely fire such a guy in my company of he would open his mouth with that kind o coments.
Edited 2011-07-10 08:58 UTC