PulseAudio Creator Responds To Critics

Dan Jones writes "As recently discussed here, Linux sound development has come under fire for being overly complex and, more specifically, PulseAudio has been criticized for not being a 'good idea.' In a lengthy interview, PulseAudio creator Lennart Poettering has responded to the many critics of the new-generation sound server and says such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people. While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications."

Comments

This is the Sound of

[Anonymous Coward]

Firrrrrsssst P Po Po sssst

Re:This is the Sound of

[Anonymous Coward]

This is the only situation that anyone says: "If it has Pulse... its dead"

Re:This is the Sound of

[Runaway1956]

You should be using OSS4. I put up with the Pulse idiosyncracies until my virtual machines spazzed out. Started researching my options, and found that Open Sound was moving past the deprecated OSS3, which wasn't much better than Pulse.

Since I've compiled and installed Open Sound, I have no more sound problems, period. Everything works the way it's supposed to.

If Pulse and Alsa get their shit together, fine. If not, I'm a devoted OSS fan. Before anyone runs off to experiment, be warned - you will probably have to spend a few minutes purging Alsa from your system. There is no co-existence of the two, at least not on Ubuntu. If you're not a Linux guru, plan on following a how-to, and plan on spending a couple hours getting it right.

http://www.opensound.com/
https://help.ubuntu.com/community/OpenSound

Re:This is the Sound of

[icebraining]

I'm an OSSv4 converted too - being being unable to get vmix or Pulse to work right, Alsa could turn the volume as high as Windows. Now in OSSv4 everything works fine, except being unable to detect the jack, which is annoying.

Re:This is the Sound of

[hamanu]

Actually I have oss4 for hdaudio, and alsa for usb audio working together on debian. It is was a royal bitch tho. I run this script instead of oss soundon/soundoff

#!/bin/bash
set -x

if [ ! -d /lib/modules/$(uname -r)/oss ]
then
                soundoff
                soundon
                mv /lib/modules/$(uname -r)/kernel/oss /lib/modules/$(uname -r)/oss
                depmod -a
fi

rmmod oss_hdaudio
rmmod osscore
modprobe osscore vmix_loopdevs=1 &&
sleep 1 &&
modprobe oss_hdaudio &&
sleep 1 && /usr/sbin/ossdetect -d &&
sleep 1 &&
sh /usr/lib/oss/etc/legacy_devices &&
sleep 1 && /usr/sbin/ossdevlinks -v
sleep 1 && /usr/sbin/savemixer -L -v
sleep 1 &&
modprobe snd_usb_audio

Re:This is the Sound of

[V!NCENT]

Turning the volume louder than the total of 0db demolishes your speakers, unless you have mid, high and lows. In other words: if OSSv4 allows you to do that then OSS sucks and the OSS devs know very little about sound other than turning data into soundwaves -_-'

Re:This is the Sound of

[QuoteMstr]

Turning the volume louder than the total of 0db demolishes your speakers, unless you have mid, high and lows.

And even if it doesn't actually damage anything, amplification can cause clipping. On the other hand, many sources really are too quiet and don't fully exploit the available dynamic range, so having a way to increase sound volume up to the point where you'd start overdriving the hardware would be nice. But that appears to be beyond the state of the art for online algorithms. (Offline, people have been normalizing volume for years.)

Re:This is the Sound of

[PopeRatzo]

When you overdrive a digital source, it doesn't get louder as much as it starts to lose information.

Unlike an old analog amplifier, which got "warmer" or increased the harmonic content when you went "into the red", a digital signal just starts to crap out.

If you want to make a sound coming out of your computer louder, you turn up the amplifier outside of the computer. You wouldn't want the audio software to do it.

Re:This is the Sound of

[dpilot]

Clipping can kill your tweeters. It generates lots of top-end harmonics, and can send more power to them than they can handle safely.

This was particularly a problem with the original Advent loudspeakers.

Re:This is the Sound of

[QuoteMstr]

Interesting. To be honest, I don't know much about speaker design. Why isn't there hardware in the speaker for cutting off the signal before it can cause physical damage?

Re:This is the Sound of

[WillDraven]

While I agree with you generally, sometimes this just isn't an option (i.e. audio source too quiet to hear, only speakers available built into your laptop).

Re:This is the Sound of

[beerbear]

They're called limiters and they exist.
But when the amplifier clips hard, it's usually not the amplitude of the signal that kills the speaker, but the unusual frequencies that get added. No limiter will help in that case.

Re:This is the Sound of

[adolf]

All these informed-sounding folks, living in some perfect netherworld that doesn't really exist. *sigh*

If I have a recording that is too quiet (for whatever reason), it is reasonable to be able to turn it up so that it's not too quiet anymore.

Not every recording is stuffed all the way up to the max at 0dB. Some are far quieter, whether on purpose or on accident. If I have a recording which peaks at -20dB, then I ought to be able to apply at LEAST 20dB of gain to it without jumping through hoops.

This is not an uncommon problem, and the best (simplest) solution is just to turn it up -- however that's done. It's been awhile since I've done any serious audio in Linux, but if PulseAudio or ALSA or whatever combination thereof requires me to buy extra hardware (WTF?) to achieve this very simple and obvious function, then it is very broken[1] indeed.

And before anyone replies and says "Oh noes! If we give the users gain, they might makes teh Distortions!!!!" This is broken in the "I'm sorry, Dave, I can't do that" sense. It's REALLY fucking stupid that the same operating system which allows you to do "dd if=/dev/urandom of=/dev/sda" without prompting WILL NOT PROVIDE MEANINGFUL AUDIO GAIN.

Re:This is the Sound of

[jhol13]

your speakers need to be rated at better than the amplifier's peak power

No.

The easiest way to destroy speakers is to have too "small" amplifier (one without enough power), not too big.

Reason: when amplifier is pushed to the limit it will clip (or worse) which will create a lot of high frequencies which will burn the (relatively low rated) high frequency element.

With high enough power your ears will control your brains which will control the remote which will control the amplifier power - down.
This very usually happens before any speaker element is destroyed (but not always). The effect on your ears is left as an non-exercise for the reader.

Re:This is the Sound of

[Rob the Bold]

You were making a good point until you resorted to profanity, which shot you right down from the sky. Such a shame.

I think you accidentally switched on the grown-up internets today. Sometimes the people use the bad words there. It'll be OK.

Re:This is the Sound of

[V!NCENT]

There is a third one: glue. Guess what? What happens when your speakers fibrates so hard that the glue cracks? Yup. You have fucked up your speakers. You see whith ear phones a lot. A workouround for this is suck and blow a little in the earbuds, but after a week or 2 or so you will need to buy ned ones. ;)

Re:This is the Sound of

[Sycraft-fu]

Probably because such a think would be expensive, and hurt sound quality. You want as few components in between your amp and the speaker as you can get. This is especially true since it is hard to make large scale passive components super precise.

I'm not sure precisely what you'd need to put in to limit power in this way, but I don't think it'd be very workable. You'd also have the problem in that if you directly measured power, you might limit the speakers in a way you don't want. After all they can handle momentary transients higher than a sustained level.

The real problem is voice coil heat. Lots of power causes the voice coil to heat up and melt, as it is a bunch of very fine copper or aluminium wire. While a temperature sensor connected to a relay would do the trick, there's no way you could get the sense where it needed to be and besides, the weight would screw things up, tweeters are very light.

All in all there's just no practical way to do it, and really there's no need. Not over driving your speakers isn't hard. Most systems (like CD and DVD players) don't allow for clipping in the digital domain, so no problems there. Pushing an amplifier in to clipping is still a problem but less of one. A good amp will have clipping prevention, and things like receivers generally can check all their gain stages and thus regulate the final output so as to not go over what the amp can handle.

Over all it isn't a big problem. If you can figure out a way to cheaply do limiting without adversely affecting audio, I'm sure that it'd be implemented. Remember it needs to be effectively passive, as the only power coming in to a speakers is the signal to drive the cones. However the fact that it isn't done, even on fairly pricey speakers, leads me to believe it isn't possible at a reasonable price point, if at all.

Re:This is the Sound of

[apoc.famine]

I'm really curious - I haven't tried OSS4 yet, but the one thing I haven't ever gotten working on linux is the following setup:
 
Analog/Digital speakers, with a USB headset.
 
Can OSS4 handle USB sound? Can it mix multiple streams? Does it have an easy way to switch between input/output devices?
 
Pulse gave me hope for the above. Then fell flat on its face. I've never been able to get dmix to handle this setup, and ALSA doesn't seem to do it.
 
I hate to say it as a linux fanboy, but I want audio like Windows. Right-click on my audio button, and in two clicks I can choose my input and output devices, and all sounds are seamlessly mixed to make that happen. I don't really care about network audio, or any of the other fancy-ass shit that pulseaudio is supposed to do.
 
Really, I use a desktop, and I have multiple audio sources and devices. Mix them automatically, and give me a quick gui control for which piece of hardware should be handling each. That's all I really want.

Re:This is the Sound of

[adolf]

Oh my gosh. *looks around* I didn't realize we were in church.

Thanks for the tip, Pastor.

Re:This is the Sound of

[adolf]

Nice.

Remember when I wrote about jumping through hoops? THAT. I don't want to have to massage every bit of quiet audio that I encounter, FAIL or not. I just want to turn it up so I can hear it.

There is PC audio outside of music MP3s on a disk, anyway. Youtube comes to mind. So does Google Voice. And so does the stuff I yank out of my pocket voice recorder. And then there's Shoutcast. And. And. And.

I suppose I should concoct a way to deal with increasing the levels of each of these things when they happen to be too quiet, just so that I can work around PulseAudio's lack of gain?

Talk about fail.

Re:This is the Sound of

[adolf]

Gosh, I never thought of that: I can just take the source audio and adjust it up with mp3gain or sox or something! How short-sighted of me. Thank you for showing me the error of my ways. [/sarcasm]

Of COURSE it's broken, but that doesn't mean it's the application's fault. Sometimes, the mic audio on (say) the camcorder is just too low, and the person running the thing doesn't have the knowledge, skill, or time to fix it. Am I really supposed to figure out how to adjust the gain on some H.264 multiplexed audio/video just so I can show a video to a friend on my laptop, with audio at a reasonable level?

Seriously?

Cuz, I mean: I don't have time to supervise every production that ever happens in every corner of the world, and accordingly things are very simply too quiet from time to time.

Really, folks. I want to live in your happyplace where all audio levels are always sane, everyone has a clue, and all volume controls are simple attenuators. I honestly do. But my reality doesn't work that way.

Re:This is the Sound of

[Runaway1956]

I'm not qualified to answer all of your questions and concerns. I DO KNOW that OSS4 handles USB speakers. I have no speakers plugged in to my sound card, all I use is the USB headset.

I also know that OSSMix can mix your multiple streams.

Since I don't switch between multiple input/output devices, I can't say.

As for analog/digital speakers, I'm lost. I THINK that you can plug in both, and even switch between them, but hell, I'm not an audio buff, so don't start me lying. ;^)

My best advice is, visit the 4Front forums, and search or post your concerns: http://www.4front-tech.com/forum/index.php?sid=dadb22fbf3e8e7037a272e7e241fa1c5

Re:This is the Sound of

[Sillygates]

Right before all the distributions started switching to PulseAudio, I remember thinking about how alsa was becoming stable (and "the" audio standard), and I wasn't seeing anyone with sound issues anymore.

Granted, alsa alone isn't as versatile as pulseaudio, but there is value in sticking to a 'pretty good' solution, even if it might not be the best.

An interesting side note on audio APIs: http://blogs.adobe.com/penguin.swf/linuxaudio.png

Re:This is the Sound of

[clare-ents]

Recording at -20dB isn't 100% FAIL. Suppose you're recording outdoors and it's windy. The difference between the ambient noise floor of the wind (say 40dB) and the spoken voice (say 90dB) gives you 50dB of dynamic range. Setting it to peak at -20dB puts the wind noise at -70dB, compared to the digital noise floor of -90dB (16bit) or -120dB (24bit). That's a perfectly sensible optimisation which gives a huge safety margin on clipping the signal whilst having the digital noise floor so low it doesn't matter. Remember when setting up you have a much better estimate of the minimum background noise level than the maximum peak - e.g. should your interviewee suddenly shout and you're recording with peaks a 0dB in normal speaking you're going to look very stupid.

In general a professionally mastered recording should peak at 0dB to use the full dynamic range, but sometimes computers are used with original content before it's been mastered.

Re:This is the Sound of

[dpilot]

Aaahh, the mystique of vacuum tubes...

But this is one of those places where they really are better. Semiconductor amplifiers tend to run right into the rails and clip hard, generating piles of harmonics. Vacuum tube amplifiers tend to clip more softly/slowly, and therefore don't generate as much higher-frequency harmonic content. That's just saying something, just like "vacuum tube amplifiers sound better", so to try and put a little technical spin behind it, I'd have to give a conjecture for softer clipping: Vacuum tubes run off of higher voltage, lower current power supplies - in other words, higher impedence. When running from a higher impedence power supply, as you approach maximum output, the local supply starts to droop, adding its own limiting action to the output. So the "clipping" is less like "abruptly clipping" and more like "gradually running out of steam."

Your dumb ol' SET tube amp has unilaterally decided to limit or prevent clipping.

Re:This is the Sound of

[shutdown -p now]

Can OSS4 handle USB sound?

Yes.

Can it mix multiple streams?

Yes (it just works).

Does it have an easy way to switch between input/output devices?

OSS is the Unix Way - audio devices are just files. An application written for OSS generally provides some way to specify the device you want to work with; this could be wrapped in a neat UI, but it really is something for UI toolkit or DE to handle, not OSS itself.

Re:This is the Sound of

[adolf]

I like the idea of a checkbox. Except, as an audiophile, I don't like one bit of what you say it should do.

I'm not always looking for perfect, pristine audio -- some of the stuff that I play on a computer is very low-fi indeed. But one thing that I'm almost never looking for is any sort of compression or automatic gain control: Just because I want to increase the level of a given work, does not mean that I want it ramped up and down automatically.

I mean: If PulseAudio would, as you propose, allow me choose between either having audio that is sometimes too quiet, or audio that is always compressed, then I'll just use Windows, thanks.

A better idea, I think, would be to have a checkbox, and have it soft-clip or limit signals at or near 0dB when activated -- this will keep the nannies happy about their "OMG! Digital clipping!" concerns. Have it do none of these things when deactivated, for the audiophiles of the world. And then, just give everyone the ability to control gain themselves, including adding (gasp!) positive gain.

Re:This is the Sound of

[Anonymous Coward]

Amen.

There is absolutely nothing magic about 0dB, it means the signal is considered to have no more/less power than a COMPLETELY ARBITRARY REFERENCE signal. If you measure in dBv, that reference is 1V RMS, if you measure in dBu, that reference is 0.77V RMS, if you measure in dBm, that reference is 1mW power, if you measure in a digital format, it can be referenced to the maximum representable signal (in 16-bit audio this is obvious +/- 32767

As the parent pointed out, if your input file has some headroom (basically the maximum signal level is less than the maximum representable level) you can increase the volume without clipping until you run out of headroom. Most modern pop/rock recording have very little headroom throughout the entire track, so as soon as you bump up that master fader things start to sound crappy, but a lot of older recordings and many well-mastered modern recordings have quite a bit of headroom, except perhaps for a few strong peaks in the music. Putting the master volume at +6dB doesn't mean the output is trying to be 6dB higher than the maximum possible output and thus clipping, it means the output tries to be 6dB higher than the input. If the input is at -20dB, than the output will be at -14dB.

In regards to normalizing, the fact that there is no real-time normalization has nothing to do with a lack of algorithms, it's because we haven't discovered time travel yet. Normalizing a signal adjusts the level of an entire track/recording by a certain amount, generally to avoid clipping and provide some headroom for the loudest parts. Without knowing how loud the loudest parts of the track will be you can't normalize. The real-time equivalent is limiting and compression, which will selectively decrease small parts of the track when it gets loud.

Re:This is the Sound of

[jmorris42]

> Each time Linux redesigns some subsystem there are problems, and we see
> the same people bitching about how we should use $ALTERNATIVE instead...

No, the situation with Pulse is different in several ways.

1. With previous changes there was pain in the transition but even those suffering most could see that the change was going to be a good thing. Not so with Pulse. Pulseaudio is a system that would be, at best, a minor improvement in a perfect world and a never ending nightmare in the real one. Harsh charge? Read on.

2. Pulse blameshifts all it's problems to apps and drivers. Ok, apps (open source ones anyway) will eventually get fixed. Drivers won't. Motherboards do not ship with sound drivers for Linux. Linux ships generic drivers for the sound chips on popular systems. There is a big difference. Board makers connect those generic chips in a myriad of ways, poorly documented if at all outside the Windows driver. Manual intervention and exploration is usually required to figure out what is connected to what and how best to configure things. Pulse's design is to remove all controls except one big volume slider.

Examples: My desktop system requires careful balancing of the VIA DXS, PCM and Master sliders to get enough output to drive my speakers and avoid clipping in the digital side of the system. My Thinkpad needs an easy way to mute the master output to silence the internal speaker while leaving the external output alone to get good results while docked. Feel free to add your story, if enough of us provide use cases where ONE slider won't work.... they will ignore all of us. :(

3. It still isn't even clear exactly what problem Pulse is supposed to be a solution to. Every major application had finally achieved stable ALSA support, and ALSA works. Being able to move sound streams between devices while they play is gee whiz and all, but it isn't a problem most of us are needing enough to endure a lot of pain to get. It might be worth the pain if we were being promised this would be THE audio solution but the Pulse devs themselves admit it isn't, Pulse can't touch JACKs realtime features.

4. But the biggest problem with Pulse is the devs. There are real problems but this time, unlike past transitions, this isn't a case of they haven't fixed all the bugs yet, it isn't even a case where they tell ya to submit a damned patch if ya want your problem fixed NOW. Both of those cases are normal examples of Free Software development. No, what is new is bugs being closed with "That problem can't exist within our philosophy and thus can't be fixed, buy new hardware and hope it works." In other words, that problem can't be fixed without exposing complexity we don't believe should exist. They have forgotten the second half of "Make things as simple as possible, but no more."

Re:This is the Sound of

[Korin43]

All of the problems I ever have with PulseAudio are related to ALSA (lack of ALSA driver). I've never had a problem with Pulse itself. And some of the cool things PulseAudio does are nice, like software mixing and network sound (very useful for projects like CoLinux). And I realize other projects have done the same thing, but the exciting thing about PulseAudio is you don't need to know that it's there for your program to work.

Re:This is the Sound of

[AdamWill]

"Examples: My desktop system requires careful balancing of the VIA DXS, PCM and Master sliders to get enough output to drive my speakers and avoid clipping in the digital side of the system."

By all means file a bug. Contrary to your later assertions, we (myself, in co-ordination with Lennart and Jaroslav) have developed a process for reporting this kind of issue in a way which provides the correct information for us to efficiently adjust things so that ALSA exposes an interface to PA which allows it to properly control your volume. Cue celebrations. See https://bugzilla.redhat.com/show_bug.cgi?id=497966#c1 for instructions.

who's to blame.

[delirium of disorder]

When an application can make the soundsystem stop working for all other applications, than there is a bug in the soundsystem, not just the application that caused the problem.

Re:who's to blame.

[Anonymous Coward]

Big deal. Scratch your itch! Check out the code from CVS and contribute a fix. Don't just sit there and complain, do something about it! This is F/OSS for God's sake.

I think you're joking up until this point...

How many people would contribute fixes to Microsoft's buggy audio drivers if they had half a chance?

... and now I think you are serious. Not everyone that uses Linux is a software developer. Not to mention, of course, that not all software developers who use Linux would have the time/skillset to approach such a focused project.

Re:who's to blame.

[GameMaster]

Um, the point here was that the developer, apparently, tried to pass responsibility for the instability onto other apps/drivers. The problem mentioned in the post you responded to implies that he's full of crap and deserves to be called out on it.

Re:who's to blame.

[xtracto]

Big deal. Scratch your itch! Check out the code from CVS and contribute a fix. Don't just sit there and complain, do something about it! This is F/OSS for God's sake. How many people would contribute fixes to Microsoft's buggy audio drivers if they had half a chance?

Bah!
As a computer user I do not have time to do that. The previous to last version of Linux I tried had this "ALSA" sound driver, which was *almost* behaving OK. Then the last version had this "PulseAudio" sound driver which was completely broken. My 10 years old Windows XP operating systems gives me no problems when playing audio.

I put the blame in Distribution makers, who added PulseAudio to "production-ready" distributions when the software is clearly in Alpha stages.

ALSA is on the other hand in BETA stage IMHO. Still, it was good enough.

Re:who's to blame.

[Jason Pollock]

Precisely. PulseAudio cost me a week of effort in building my media playing machine. An entire week of trying to figure out why XBMC and Boxee wouldn't talk to the sound card.

As soon as I got rid of PulseAudio? It started working.

When an API is supposedly compatible with something it is replacing, it is the _API's_ fault when an application stops working, not the application. We already had this argument with EXT4.

PulseAudio - not ready for prime time.

Re:who's to blame.

[phantomcircuit]

I believe that he was saying PulseAudio was calling low level ALSA apis that are not often used and as such many drivers have never actually been widely tested. So PulseAudio is causing the drivers to crash.

I do not believe he was saying that an application connected to PulseAudio should not be able to crash PulseAudio.

Re:who's to blame.

[ta bu shi da yu]

Well, if the software calls on a driver, and the driver has a bug and crashes, then it's the fault of the driver. Therefore, fix the driver. Simple! Why is this so controversial?

Re:who's to blame.

[Runaway1956]

I'll stick my neck out here. First, Pulse relies on the Alsa driver. There is no hardware issue, and the driver issue seems to be the Alsa driver. OSS4 works on my hardware, where Pulse and Alsa failed. And, of course, the Windows sound drivers work on that same hardware.

People with sound issues on Alsa and Pulse should try OSS4.

Re:who's to blame.

[mickwd]

I'm also slightly disturbed by his attitude to other operating systems than just Linux. For example, this post on the OpenSolaris mailing list.

Comments such as the following:

Then, "Unix Admin" asked mumbled something about whether we might want to install Solaris on my machines. Thanks, but no thanks. I already got a good operating system, which is called "Fedora", and its audio system is what I am payed to work on by Red Hat.

As mentioned above, we have been adopted by all relevant Linux distributions. There's not much left we could win in Free Software land, except maybe that little OS that starts with "Slow" and ends with "aris". ;-)

appear somewhat unprofessional for someone who is being paid for the development he is doing, and for someone on whom the future of Unix/Linux audio has been entrusted.

Re:who's to blame.

[John Betonschaar]

Same here, yesterday I spent 4 hours on a media PC I built and configured for my brother in law, up to the point that everything worked at my place using SPDIF output (which already cost me 2 hours to get working in the first place). I arrive at his place, turns out he wants to use the HDMI output instead of the SPDIF. No problem, you'd guess, just go to the sound preferences and select HDMI, right? Not on linux you don;t and not with PulseAudio apparently. After dicking around with the 4 different mixers (gnome, alsmixer, pulseaudio) and 4 layers of configuration (gnome sound settings, pulseaudio settings, alsa settings, gstreamer settings) it turned out that I had to put a file called .asoundrc with some cryptic content in my home directory, and in some tab called 'switches' in the PulseAudio advanced settings had to check 4 boxes that did something with an 'iec958' (whatever that may be) and then, finally, it worked. Not very well by the way because the Ubuntu startup sound pops and stutters like hell, but after that it's more or less 'ok'.

I've been using Linux for over 10 years now and I've been telling people over and over again how even your grandma could use it, but sadly, I have to conclude that in some ways it still sucks balls for people who don't like fiddling around with obscure settings, configuration files, 4 layers of sound settings etc. I really love linux myself but let's face it, for example sound and wireless (damn wpasupplicant and 'wlan0: link not ready) are still lightyears behind Windows and (even more so) OS X in terms of usability.

Re:who's to blame.

[aaribaud]

In TFA, Lennart P does explicitely explain that he does not pass blame, and details the causes and implications of his statement. But of course one needs to RTFA to realize that.

Re:who's to blame.

[jelle]

Right, good to see I'm not the only one that has found that pulseaudio (and arts and esound before that) creates more problems than it fixes, today.

Maybe those future features are cool, but I have not seen them work yet, and I don't want those features more than the headaches that pulseaudio gives today.

Compare video and 'compositing', and '3d effects'. Luckily, that works well for me now, but it didn't in the past, and still doesn't work (completely) for many people. When compositing or 3d effects don't work for your system, then either is has already been switched off automatically, or you can switch it off easily in the system settings (and even with a special three-finger salute (alt-shift-f12)), and you system will work as if compositing and 3d effect never existed. It never breaks video on your system.

That's the successful way of making such an invasive, and initially often broken, improvement in a service. Nobody got angry at compositing and 3d effects, except when they wanted it and couldn't use it because it didnt' work (well) on their system, but at least then their systems worked fine without it, they just didn't get the features it gave.

Some of the people who where experiencing problems with those feature were able to test with it and report problems/bugs in detail to the developers, and still be able use their systems in daily use after disabling the features, providing useful feedback to the developers, instead of providing hordes of angry, unhelpful, users that the developers needed to 'defend' themselves from.

That's how pulseaudio should be.

Pulseaudio today has no place in a distribution other than an optional addon for people who want it, or at the very least, it must be possible to completely and utterly disable it with a simple, easy to find, single checkbox in the sound configuration menu of the system settings program. In ubuntu, it is installed by default and is listed as required in the dependencies and build-deps of too many packages, which it shouldn't, because 'it breaks stuff'. And after you have it, it's a major pain to try to disable or uninstall.

I find that my audio works fine without pulseaudio, so why would I have to use a still buggy program under development that is messing around with my audio, using up memory, using CPU, adding latency, causing audio to be choppy sometimes, and most of all, making applications that try to use audio be silent or sometimes even hang. What is up with kde that every time I click on a pulldown menu, that it needs to call a pulseaudio function? (replace /usr/bin/pulseaudio with a script that does 'sleep 5' and killall pulseaudio, and you'll see what I mean). Where else is there pulseaudio overhead that makes the desktop programs less responsive?

Perhaps pulseaudio itself is still buggy, but then it shouldn't be enabled by default and in so mamy package's required 'build dependencies', it should only be enabled for people who specifically choose it, and when building a package, it should not be listed in the build-deps.

Pehaps it can't be fixed without first changing thing elsewhere (kernel, sound drivers?), but then it's the same conclusion; It's still not ready for prime time. Fix what needs to be fixed first.

Perhaps it can't be fixed ever, then it should be removed.

Re:who's to blame.

[Larryish]

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.

Re:who's to blame.

[John Betonschaar]

Well I know for a fact that I could do almost that using esound and artsd like 5 years ago, except for the 5.1 part (only stereo). Not that artsd or esound were fantastic, but at least both worked, both worked without requiring elaborate configuration, both worked straight on top of ALSA, neither had skipping or popping playback and also, neither of them ever broke a working configuration on any of my machines.

The whole idea behind PulseAudio sounds great, except that 99 out of 100 people simply want working sound out of the back of their computers, over any of the ports the card has available. If I have to spend 4 hours to get to that point, the thing is not ready for prime time.

Re:who's to blame.

[lisaparratt]

Yet I still can't play audio out of the speakers built into my laptop.

There's still a damn long way to go.

Re:who's to blame.

[Ant P.]

I don't think that "gnome attitude" ever went anywhere. I've seen at least 5 or 6 GNOME-related projects that are run by people or groups of people who act like this, or even worse (Mono doesn't give a shit unless you're using Ubuntu).
No other software development group I've seen is as collectively rude as GNOME, they're like the 4chan of FOSS.

Useless

[Carewolf]

The idea is great. PulseAudio is an excellent solution for networked audio and thin unix clients. Now the problem is the people and the distros installing it by default on a desktop where it is utterly useless. No matter how close to bug-free it is, it is an unneeded source of bugs in that case.

Re:Useless

[Cyberax]

PulseAudio is NOT unneeded.

First, Bluetooth audio _sucks_ without PulseAudio.

Second, you NEED to have a sound daemon to properly manage the sound system and other sound daemons suck.

Third, ALSA's volume controls are horrible and PulseAudio really helps here.

Fourth, PulseAudio has a ton of other nice features: streams tagging and automatic volume control, joined devices, mic boost, etc.

Re:Useless

[Anonymous Coward]

...Fourth, PulseAudio has a ton of other nice features...

Now if only it would actually play music without skipping, freezing, or using 30+ percent of the CPU. Sheesh!

Re:Useless

[Anonymous Coward]

Networked audio and thin unix clients ... just what I need at home! I do hope that my netbook can stream PulseAudio to my PDA!

Re:Useless

[Ant P.]

The problem is the fact PulseAudio is designed to be used only in that utterly useless way.

Want to run mpd? Too bad, PulseAudio doesn't run as a system daemon. Want a headless server? Too bad, you have to have GNOME running on it and be logged in for this to work properly.
Want your damn sound card to just work already? 99% of the answers will be "uninstall PulseAudio". A better answer is to not use a distro that dumps it on you in the first place.

Re:Useless

[J Story]

PulseAudio is demonspawn.

OSS -- *not* the old stuff that comes with most distributions, but the Open Source OSS v4 at opensound.com -- is a better alternative to ALSA and the PulseAudio abomination.

Re:Useless

[Anonymous Coward]

From the wiki http://www.opensound.com/wiki/index.php/Main_Page:

Supported audio formats
- Supports 8/16/24/32 bits/sample audio formats
- Supports sampling rates from 8KHz up to 200KHz
- Supports mono, stereo, quad, 5.1, 7.1 and multichannel audio devices
- Transparent Software based Audio Mixer
- Allows applications to share the same "real" audio device regardless of what format is requested by the application.
- Supports recording and full duplex in addition to playback.
- Ability to mix stereo and multichannel audio streams up to 7.1/200Khz/32bit.
- Supports full 24 bit range without loss of precision during internal computations.
- Each application has its own independant volume controls.
- Supports loop back recording. This enables you to "record-what-you-hear". Typically this is useful for recording streaming audio or trapping audio from applications
- 64bit internal processing guarantees audio fidelity and precision if the audio data needs to be converted.
- New device enumeration and mixer API makes it very easy to manage devices programatically.

Re:Useless

[Per Wigren]

Now if only it would actually play music without skipping, freezing, or using 30+ percent of the CPU. Sheesh!

It will, if both your kernel and Pulseaudio are properly configured for low-latency desktop usage (realtime privileges, 1000hz timer, etc). While I fully understand you being annoyed that your current distro/version ships with a default configuration that isn't fully adjusted to this very common usage pattern, it also means that the situation will get better as distributions learn how to properly integrate Pulseaudio and the remaining bugs in Pulseaudio itself are fixed and it gets better at automatically detecting and adjusting to different hardware setups. This includes making the ALSA drivers better at reporting which jacks are plugged in and things like that.

Re:Useless

[setagllib]

Ok, what? It definitely works as a daemon. But even if it didn't, what's the issue? If you have a dedicated headless MPD server, you gain nothing by using Pulse. If you have plenty of desktop applications that all want sound input/output, Pulse solves basically everything.

Re:Useless

[mickwd]

It definitely works as a daemon

On Gentoo:

desktop ~ # /etc/init.d/pulseaudio start
* Please don't use system wide PulseAudio unless you read the
* documentation available at http://www.pulseaudio.org/wiki/WhatIsWrongWithSystemMode
*
* When you're done, please set the variable PULSEAUDIO_SHOULD_NOT_GO_SYSTEMWIDE in
* /etc/conf.d/pulseaudio . Please remember that upstream does not support this mode
* when used for standard desktop configurations.
* ERROR: pulseaudio failed to start

Quoted from that link: "The maintainer's interest in making sure system mode is well supported is rather minimal."

Re:Useless

[shadowknot]

The idea is great. PulseAudio is an excellent solution for networked audio and thin unix clients. Now the problem is the people and the distros installing it by default on a desktop where it is utterly useless. No matter how close to bug-free it is, it is an unneeded source of bugs in that case.

But not for dual-boot workstations where users' home dirs are samba shares as it leaves symlinks to /tmp in the .pulse directory of each user that, when a user logs on to a different workstation, prevent Gnome from loading unless the pulse processes are killed. We have had to dump pulse in favor of esound (I work at a University) which doesn't have these issues. Sound, thankfully, isn't that critical on our dual boot XP/Ubuntu boxes but pulse has caused us all manner of issues with these pesky symlinks. I don't think the way our institution does home dirs is especially clever but it's not uncommon.

Re:Useless

[Richard_at_work]

So we should forgive what is to most people a shitty application its sins because it solves a problem the majority of people don't give a crap about?

Thats the underlying problem here - the creator may indeed be correct when he says that 'such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people', but those people are outweighed by the non-technical masses suffering a bad experience.

Re:Useless

[Cyberax]

"Thats the underlying problem here - the creator may indeed be correct when he says that 'such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people', but those people are outweighed by the non-technical masses suffering a bad experience."

The problem is, Linux audio is broken and it HAS to be fixed. PulseAudio just exposes the problems in it. And you can't fix these bugs without user input.

Re:Useless

[Runaway1956]

"OSS is outdated and has its limitations. "

OSS3 was proprietary, it had limitations, and it sucked.

In today's world, OSS4 is open source, it is actively being developed, and it WORKS! See my post above. I can have three virtual machines open, all of them playing sound, and go back to the host machine, and play music there. No sizzle, no popping, no waiting for buffers.

OSS4. I don't understand why more people haven't discovered it yet. If the idea of compiling scares you, don't mess with it - but I really thought the majority of Linux systems could figure it out.

Re:Useless

[jedidiah]

> First, Bluetooth audio _sucks_ without PulseAudio. ...which means that all of us without "bluetooth audio" couldn't care less.

> Second, you NEED to have a sound daemon to properly manage the sound system and other sound daemons suck.

No you don't. No they don't.

For the mundane user, ALSA was doing fine before Pulse came along. For most of us,
PulseAudio was a solution in search of a problem and just something else with more
moving parts to break. Even now, most users would be best served by just un-installing
PulseAudio entirely.

Re:Useless

[vadim_t]

IMHO that sucks donkey balls.

The exact system component that is supposed to mix audio from all applications only works so long it's all under a single user account. The moment user switching comes into play there's got to be some horrible hack to release control of the sound device so that another instance of PA can get it, and if I for any reason want to run an application under another account (for security reasons for instance), it doesn't work anymore. Isn't that wonderful?

Here's what I want: That sound ALWAYS gets mixed. No ifs, no buts. System-wide for anything at all that tries to play sound.

Re:Useless

[segedunum]

It will, if both your kernel and Pulseaudio are properly configured for low-latency desktop usage (realtime privileges, 1000hz timer, etc).

This is bullshit. No one should ever need to configure a sound system to get it to work on a basic set up and I'm sure that blaming distros or blaming kernels looks like the easy way out. No one needed to configure OSS, no one needed to configure ALSA and no one has needed to configure arts to get sound out of their speakers reliably on first start up. I've seen the mail where Lennart is blaming various Linux kernels for several hundred millisecond latencies and that is simply insane. Either he's lying or you've got a piece of software that is ridiculously sensitive and ultimately broken.

This includes making the ALSA drivers better at reporting which jacks are plugged in and things like that.

Then fix ALSA or use OSS before you start retrofitting bullshit sound servers that breaks a lot of things. We've had an unhappy history with sound servers in the Linux world and no one seems to have learned the lesson.

Re:Useless

[Anonymous Coward]

The point is, we aren't interested in compiling our own kernels (I'm a developer and I try to avoid it as much as possible). That's what distros are for and that's what they're pretty good at. Now, distribution builders have learned the hard way that anything outside mainline kernel is a problem in the longterm. Kernel developers in their part have clearly stated that OSS4 is really far from being accepted into the kernel.

That's the reality: Users trust distros, distros trust kernel devs. Unless OSS4 gets into the mainline kernel, it is dead and deprecated. Based on what I've seen of OSS4 and the people working on it, it will never make it.

This may sound harsh but my guess is that netcraft will confirm the fate of OSS real soon now.

Re:Useless

[Runaway1956]

A more complete quote from your link:

Q: Is everything in OSS open sourced?

A: No. There are three drivers that have mosty been written by the hardware manufacturers. We are not permitted to release their sources unless their authors as us to do so.

Also some parts of the envy24 and envy24ht drivers contain some code written under NDA. We have not yet received the approval to open source the code from all manufacturers. So these drivers cannot be open sourced just now. If we don't get the approval in reasonable time we will distribute these drivers with the offending code stripped from the sources.

Finally there are some effects in the old softoss driver that are not included in the source packages. We will make the decision about their future later. At this moment it looks like we will remove the softoss driver from the OSS package so these effects will not be used in OSS anyway.

We reserve the right to include some "closed source" drivers only in our binary distribution if the hardware manufacturers refuse to give the programming specs without NDA. Our policy is to promote open source but not to enforce it. We will let hardware manufacturers to decide if they like to select the commercial distribution mode instead of the open source one with much wider customer base.

http://www.4front-tech.com/forum/viewtopic.php?f=19&t=2411
OSS now released under BSD license

Postby dev Fri Jan 04, 2008 8:36 am
We are releasing the FreeBSD version of Open Sound under a BSD license and we hope that the BSD community steps up with ports for NetBSD and OpenBSD and enhancement to FreeBSD ports.

http://www.4front-tech.com/forum/viewtopic.php?f=19&t=2139
Open Sound System is now open sourced!

Postby dev Thu Jun 14, 2007 4:16 am
We're releasing the source code for Linux/Solaris/FreeBSD/Unixware under CDDL/GPL licenses - get the source at http://developer.opensound.com/

We thank our paying customers for keeping us in business all these years - and we now hope that no one has a reason to not use OSS because it isn't open sourced.

Best regards
Dev Mazumdar

http://www.opensound.com/wiki/index.php/Building_OSSv4_from_source

Contents
[hide]

* 1 Building the OSS sound system from source
o 1.1 Requirements to build the source code
o 1.2 Building the source
+ 1.2.1 Obtain the OSS source
+ 1.2.2 Change to the source directory
+ 1.2.3 Extract the source tarball
+ 1.2.4 Create a build directory, and make it current
+ 1.2.5 Run the configure script
# 1.2.5.1 Notable configure switches
+ 1.2.6 Run make build
+ 1.2.7 Packing Open Sound System (

Durability in the face of errors

[ZorbaTHut]

If we make PA expect more correct behaviour from the apps, or that applications stop making particular assumptions about the audio stack, we need to fix the applications at the same time.

This is not entirely true.

Now, I don't know what the exact bugs are that are causing problems. But the API should be stable no matter what happens to the outside. There should be no way to destabilize or crash the audio layer from a usermode application. So, if by "expect more correct behavior from the apps" he means "garbage in, garbage out", then that's fine. But if by "expect more correct behavior from the apps" he means "no error checking and if any app screws up then everything melts", then that's not fine.

I don't know which he means, but I've seen instances of both.

Re:Durability in the face of errors

[abigsmurf]

It's actually extremely difficult to do a reliable sound system. The drivers for a large number of cards are pretty bad.

From what I understand up until recently most OS' treated sound cards like any other hardware. If you got a bad response from them, the OS would halt the system rather than risk physical damage. Hence sound cards are one of the leading causes of blue screens in windows 9x and XP.

One of the things Vista did right was recognise that drivers for sound cards can't be trusted and put in an additional software layer between the hardware and drivers to minimise sound card related blue screens. It's why Directsound has been removed from DX and one of the biggest reasons DX10 can't run on XP.

Re:Durability in the face of errors

[abigsmurf]

Ah the old DRM FUD is still alive and well. Last time I checked, XP was perfectly happy to comply with the Blu Ray DRM.

DirectSound works like this - application > directsound > drivers > hardware UAA works like this - application > UAA > hardware

Re:Durability in the face of errors

[Sycraft-fu]

A correction here is that DirectSound has not been removed, it is still a major API. What has been removed is hardware acceleration of DirectSound. In Vista/7 all DirectSound audio is software processed. The soundcard can't accelerate any of it.

The real problem was actually that there were few hardware sound accelerators on the market. Most cards were (and are today) little more than buffers you could write data in to to be played. Ok, fair enough. However what happened was that the people who made these cards wanted to support all the nifty hardware features since games made use of them. So they'd write these big complex drivers that played make believe and pretended to do hardware acceleration, all in the kernel of course. That is where the problems happened.

So in NT 6 (Vista and 7) that was removed. All audio is handled in software, and the interface to hardware is just one of giving out the finished sound to be played. Much less room for problems, though more computationally intensive. Not a problem though since processors are much faster.

Hardware acceleration now can only be done using other APIs. That is how Creative Labs does it. They implement OpenAL (their own API) on their cards in parallel to the Windows APIs. It talks straight to the card, bypassing Windows's processing.

That's not the only big usermode DirectX related change though, the graphics subsystem was moved in to user mode too. Though this still does hardware acceleration, of course, the drivers were all moved up to user space. One side effect of this that you notice is that when you install new drivers, you don't need to reboot.

Re:Durability in the face of errors

[makomk]

Aureal folded

By "folded" you presumably mean "were destroyed by Creative using bogus lawsuits".

The problem isn't the idea

[amorsen]

The problem is that the implementation sucks, and that bugs are being ignored.

I'll perhaps reconsider my stance when pulseaudio starts using less CPU than the JVM when playing Puzzle Pirates. Finally something more bloated than Java, I guess.

Re:The problem isn't the idea

[QuoteMstr]

The problem is that the implementation sucks, and that bugs are being ignored.

No, the problem is that the implementation sucked. Past tense. There were various CPU-eating problems. They were fixed a long time ago.

Really, the entire Linux sound system sucks. PulseAudio is one of the better parts of it. But because PulseAudio is visible, and because an old distribution once shipped with a CPU-eating PulseAudio, it makes the perfect scapegoat today.

Re:The problem isn't the idea

[amorsen]

They were fixed a long time ago.

You can write that as many times you want. That doesn't make it true.

and because an old distribution once shipped with a CPU-eating PulseAudio

Fedora does have an aggressive release schedule, but version 11 doesn't qualify as old yet.

Why do I care where the bugs are?

[jonaskoelker]

While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications.

Well, the way I see it, I can either use alsa and have (as far as I can tell) no bugs, or I can use PulseAudio and have more features and more bugs.

That might not be PulseAudio's fault, but it still means that if I use PulseAudio I will have a buggy sound system. Why do I want that? Why do I want it even if it's only buggy until all the applications get fixed?

Also, the promise of networked sound is kinda... meh... maybe I'd be happy if all my laptop sound got moved to my desktop box (which is connected to my stereo) automatically whenever my laptop is connected to my home access point (and, conversely, my desktop's sound automatically gets routed to my laptop whenever my laptop does an ssh home and is not around my home access point). But as far as I can tell, this is a bitch to set up, and I'm really not inclined to go clicking around some unintuitive menu system to set my sound up right every time I leave home or go back.

So what's the benefit of PulseAudio again?

Why is OSS no longer in the kernel?

[Valdrax]

I've read the background articles (but not the featured rebuttal about PulseAudio yet), and I was wondering why OSS was "deprecated" in favor of ALSA and whether (and if not why not) there's a possibility of OSSv4 being put back into the kernel. Anyone know?

Re:Why is OSS no longer in the kernel?

[Ant P.]

OSS was deprecated because 4front pulled the rug out from under users and started demanding money for binary-only versions, and it was easier to write an entire API from scratch instead of trying to fix the crap they'd left in the kernel.

OSS4 is never going in because 4front has a dangerously wrong idea of how the GPL2 works and think they they have the right to infect applications using this API with their licence.

Do not want!

Re:Why is OSS no longer in the kernel?

[LizardKing]

The 4Front interpretation of GPLv2 is irrelevant - the source code is triple-licensed under GPLv2, CDDL and BSD licenses. ALSA is an excellent example of Linux throwing away a solid API and implementation that could have evolved to support the few critical features it lacked (which is exactly what happened in FreeBSD for example) in favour of a half-baked alternative. The original ALSA API is poorly designed by people who clearly have very limited knowledge of OO principles, but wanted to apply them all the same. This piss poor API was never well documented, and the actual audio drivers are not of the same quality as the ones in OSSv4. The ALSA developers answer to the poor API? Slap another, equally poor, equally undocumented API on top of it. What a fucking mess.

Re:Why is OSS no longer in the kernel?

[DangerFace]

Sorry, I still don't get it. They've been building OSS4 for years, it seems a good tool for the job, and yet it cannot be included in the kernel or distributed by various distros ? If they add trouble understanding GPL 5 years ago, ok, but isn't there any communication between 4front and the rest of the community on the subject. Weird.

Kind of like if you went to synagogue regularly, became part of the local Jewish community, and then went in one day wearing a Swastika armband and started screaming about how you'd sue them for slander if they kept insisting that the holocaust happened. /Godwin

OK, so maybe not exactly the same, but they were a part of a community that places a high value on ideas like openness and trust, and then they pissed all over that. Now no one wants anything to do with them because it's simply not worth getting sued over it, especially when users can just install it themselves if they care so much. I know I couldn't afford a lawsuit with these folks.

Re:Why is OSS no longer in the kernel?

[blind biker]

Meanwhile FreeBSD doesn't give a crap about what zealots want or do not want, and does just fine with sound.

Re:Why is OSS no longer in the kernel?

[sjames]

I have a few apps I maintain where audio is central (without audio, the apps do nothing). One is rather old and uses OSS (or the OSS compatibility driver) the other is Python and uses the ossaudiodev module. Given that OSS might be going away entirely, I looked at the alternatives.

I heartily agree that ALSA is a nightmare.If that's the only answer, I'll just retire the apps. Perhaps if there was something like documentation it wouldn't be so bad, but based on the "simple" example code out there, I'm thinking it would just be a documented nightmare. Please shoot Alsa in the head and put in a real audio API!

Given that, I can well imagine a lot of apps where sound is incidental would just forget about the audio. It's no wonder that the years depricated kernel OSS compatibility driver is still in heavy use. In the Free Software world that's a hint that the new "favored" API is a loser.

OTOH, I find that pulse works quite decently on my systems. There are some bogosities, but they can be solved. I don't see why it shouldn't run as a system wide daemon by default (it wouldn't actually have to run as root to do that). However, in spite of that, it works and it has an actual documented API that doesn't require a 4 year degree in PulseAPI to understand and doesn't require a library several times the size of my entire app. It even has an 'as advertised' simple API for apps that don't need anything fancy from the sound system. It's just fine if the objective is (as it is for many apps) just output this audio when I say so.

I was able to drop in support for pulse audio in minutes starting with nothing but the libraries and a couple pages worth of documentation. The next release of my apps will try pulseaudio and is it isn't available will fall back to the old OSS interface. If that's not available either, they'll just print an error message and exit.

Among other distros, Ubuntu...

[jonaskoelker]

Now the problem is the people and the distros installing it by default on a desktop where it is utterly useless.

In fact it's worse than useless (on Ubuntu): whenever I move away from my wireless access point at home (i.e. I'm on my bike on my way to the university), my sound stutters; this is probably PulseAudio spending too much time on making a new map of the network and too little time on actually handling sound waves (but I'm speculating).

Did no one test this? Am I the only person using a "ThinkPod" as a portable music player? Oh, I guess it's not one of those 95% most common use cases, so it's no biggie if it isn't handled properly.

Except that there are twenty disjoint chunks of 5% least common use cases not being fixed because they don't affect that many people, except everyone is affected by one... grr... </hyperbole> <apology/>

The uninformed must improve their deficit...

[Syniurge]

here: http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/

Re:The uninformed must improve their deficit...

[Yfrwlf]

"So where is Sound on Linux? In my opinion it's in a pretty good state"

If you call crackling system sounds on every computer I've ever tried Pulse Audio on as a "good state". It definitely wasn't ready to be the default.

Too many choices....

[Max Romantschuk]

The largest problem with Linux audio is not really any particular driver model / sound server. OSS, ALSA, PulseAudio and Jack all work when set up properly, with supporting hardware, and supporting software. But it's never a given that a particular app will support whatever you're using, or give you the choice to select your output device if you have multiple sound cards.

I've been running Ubuntu for a long time now, and recently installed Windows as a dual boot for making music. Why? I can spend X hours on setting stuff up, or I can spend X hours on making music. I can simply count on any app that matters supporting ASIO or DirectSound on Windows.

While I actively try to convert people to Ubuntu for regular desktop apps I still tell people who plan to do audio/video stuff to go for Windows/OS X. While it's totally doable to set up a working environment in Linux if you know what you want and which apps you want, I like to play with stuff for fun. I'd rather invest my time in having fun creating content than trying to get stuff to work.

(And yes, I've tried Ubuntu Studio. Nice, but not there yet for me.)

Re:Too many choices....

[Anonymous Coward]

A common problem, not helped by the tendency of people to reinvent the wheel (and the interfaces). Very much a linux problem, though.

Point in case? ifconfig. There's been what, two supposedly better interfaces both completely incompatible with everyone else's (read: other unices). And then you need a separate command for the low-level stuff (ethtool), or even a suite of commands to do the same (iwconfig/iwlist/...) with vague documentation and prominently featuring things already moved to a different command with no mention this is the case.

Ah, documentation. On linux, most entries in the online reference manual (`man pages') send you off to *censored* info requiring a *censored* "info viewer" that expects you to know emacs and two to one will give you the manpage again only this time you need *censored* emacs contortions to get out of dodge. Couldn't it just bail out and tell me there was no info? Nevermind, I knew that already. I'll move on to a different system. In my case, still a unix, but no linux, kthx.

Should I mention the three, no four, wifi stacks in linux? Why isn't there just one that does it all? What about bluetooth? USB cameras? Video? Similarly: The VM. The Scheduler. I'm sure there are many more examples right round the corner, for reinventing wheels for the sake of reinventing wheels is the linux way. Reinventing wheels squarely for that special corporate sauce enhanced taste is someone else's game, but rightly there isn't much difference for the end user.

Compare with FreeBSD's ifconfig: It does all that, isn't hopelessly buggy, supports modern notations, and can be extended further should the need arise. And it still is compatible with everyone else's ifconfig and no nagging it has something else that's supposedly better only nobody tells you why, or how. Also: Only one wifi stack. One sound system. Ok, so there's three packet filtering interfaces, but at least you can use them concurrently if you wish, and all of them work with all the supported hardware. My point? There are non-windows systems Out There that are well integrated, but none of them are called linux, or gnu.

As to network audio, I'm not sure I want it on that level, there. Unix has always been easily extensible even if through the virtue of a small shell script and a few judicious triggers. So I come home and drop my laptop in the network, what's to stop me from having dhclient trigger a script that sets up simple streaming to my stereo? Heck, I could stream over FTP if I wanted to. Why do I need pulse audio and its horde of bugs for that?

Re:Too many choices....

[yanagasawa]

I have to reply. I've been using Linux Audio for years making music. I rarely have to do any setup even after a system upgrade. If you use Jack and applications that support it - of which there are many, it's stable as a rock.

Re:Too many choices....

[makomk]

Should I mention the three, no four, wifi stacks in linux? Why isn't there just one that does it all?

The Linux kernel has exactly two WiFi stacks: an old one which drivers are being migrated away from, and the new improved one. The old one was abandoned because it wasn't that great and Linux was effectively given a far better one for free by a generous company.

(There's also various out-of-tree WiFi stacks, like MadWifi and a whole bunch of open source drivers provided by hardware vendors. A lot of these exist because vendors typically have their own internal WiFi stack already for Windows use. These drivers have mostly been made obsolete by in-tree drivers using the normal in-tree WiFi stack.)

As to network audio, I'm not sure I want it on that level, there. Unix has always been easily extensible even if through the virtue of a small shell script and a few judicious triggers. So I come home and drop my laptop in the network, what's to stop me from having dhclient trigger a script that sets up simple streaming to my stereo?

That's fine if you just want to stream media files. Now imagine you wanted to send the sound for arbitrary applications over the network, and the applications mostly weren't designed to support this. No way to do that easily without something like PulseAudio, especially if you want to switch where already-running apps send their sound.

Who knew?

[PCM2]

Lady Gaga apparently uses Linux.

Distribution problem

[LS]

I've read in several places that the main problem with PulseAudio is not its design and implementation, but its instantiation. Many distributions apparently do not properly set up PulseAudio, causing it to behave unexpectedly. I found this to be the case with Ubuntu 9.04. PulseAudio worked like crap until I followed the following directions to get it set up. It's been working like a dream ever since:

http://ubuntuforums.org/showthread.php?t=789578

LS

Re:Distribution problem

[zdzichu]

You may be interested that Ubuntu isn't the best at PA integration.

Yes, it cannot be pulse audio's fault, because:

[Anonymous Coward]

If you disagree with this guy, you're OBVIOSULY not "technical" and CERTAINLY not part of this mythical "vast majority".

Look, if you have a nice idea and it involves stacks and stacks of layers and drivers and the whole introduces a nice fat latency by design, and that nice idea pertains to something potentially very latency sensitive such as the audio to VoIP, then perhaps the nice idea wasn't so nice after all. And then there's the rest of the complaints.

I think "vast majority of technical people" is poetteringspeak for "yes men". Either that or he can show us wrong by patching all those drivers that he's pointing to. No, merely pointing elsewhere is not enough. Show us the code.

Can I tell it to go away when I don't need it?

[WWWWolf]

I disagree with the original article: ALSA is the way to go, I have drivers for all cards I've thrown at it, all applications imaginable that support ALSA work just fine for me, and no, as a OSS-to-ALSA changeover survivor, I don't want to change everything to another frigging API yet again (much less back to OSS), thank you very much. And while PulseAudio is less than perfect right now, I recognise it has uses.

But that's just that - it has uses. In its current state, I'm not using it for plain-ordinary music playing on my Debian system. I don't think it's ready enough as a common day-to-day audio routing thing. Still too many problems.

An example case: I was really disappointed when I upgraded Ubuntu on an older computer (600Mhz Pentium III with 256M memory and ESS Solo 1 onboard audio, plenty good enough for OpenOffice.org and web browsing, even ran Compiz at very good performance on GeForce 2 MX =) and sound playback started to just plain suck, when it previously worked just fine with straight-up app-to-ALSA playback. The machine just wasn't fast enough to route stuff through an application, plain and simple. And now Ubuntu foisted PulseAudio in. Uninstall PulseAudio = uninstall entire frigging GNOME desktop. I kept trying to tell it "no, I just want ALSA playback" in sound settings. No dice, pulseaudio kept respawning and hogging audio device all to itself. I kept disabling shit from all places imaginable. No dice, pulseaudio kept respawning. Now, I'm going insane (an unrelated story). I'll be armed with GCC and some dummy binaries. Mheheh. Muahaha. MUAHAHAHAHA. ...any better ideas?

Or not...

[bradley13]

Shockingly, I know, but I actually went and read your bug reports. You were specifically asked to file separate bug reports for separate issues. The original report was closed on the assumption that you would do so. Whether that is a good approach or not? One can debate that. But you were not ignored...

Way not to get the point: why users are angry

[Idaho]

While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications.

Even if he may be 100% right about that: way not to get the point!

I don't care whether problems are caused by the kernel, a driver, an application, the phase of the moon, or whatever. The thing is, if some "trivial" piece of hardware which has been part of mostly every computer since about 1990, still *does not fucking work* correctly today, I don't give a rat's ass whose fault that is. Especially if it appears the same "problems" have been solved satisfactorily at least 10 years ago on every other OS in mainstream use.

In the meantime, Linux has changed both the audio driver model (ALSA, OSS, who knows what else), and in addition to that, the "application interfaces" (arts, esd, PulseAudio, etc.) so frequently, that it is hardly any wonder that application developers are taking the piss and not updating their software to match the bugs/workarounds to whatever the current "flavor of the week" API for audio interfacing is.

Perhaps PulseAudio is just getting most of the "blame" because it is the most recently changed part of the audio subsystem, so if things used to work before, and now they don't, of course you're going to blame PulseAudio. Even if it is not by itself the "real" culprit.

Re:It may be buggy...

[batkiwi]

Do more than .0001% of linux users need autoforwarding, or network transparency at all? Or should we focus on what the other 99.9999% want, which is high performance, low latency, non-crashing sound like the other two major OSs have.

The Vista Defense!

[Beelzebud]

I never thought I'd see a Linux advocate use the Vista Defense! It's the drivers, it's the software, it's something, but it's not my code!

At least with Vista the problems with video drivers, and various other hardware devices was sorted out within a couple of months. In Linux the way audio is handled is an absolute mess.

Re:The Vista Defense!

[abigsmurf]

Ironically, Vista has a very solid sound system designed around the fact that audio drivers are a mess.

Article is doomed to failure, but PulseAudio isn't

[colin_s_guthrie]

I knew as soon as I read the headline here that this article would be jumped on by numerous "alsa is fine on it's own", "Why not OSS" and "PulseAudio is buggy blah blah" type posts but I didn't think that even the general slashdot hordes were that ignorant about what the hell PA is all about. I was sorely mistaken.

PulseAudio is very little to do about "networked audio" which everyone and their dog seems to use as an example to reason "I do not need networked audio, therefore I do not need pulseaudio". It's just ignorance in the extreme.

PulseAudio as an architecture is fast becoming the defacto standard on Linux, companies such as Intel, Nokia and Palm are putting significant resources into PA just now.

OSSv4 or older flavours simply does not have the API to deal with a modern linux desktop, plain and simple. We can maybe get some of the more userspace stuff such as bluetooth or airtunes support (the support for which I added to PA myself) using some kind of CUSE support but that's only just landed in the kernel just now, and it really wouldn't be a proper solution (and guess what? it would need a daemon running anyway!!)

As a PA developer and supporter, I've written up various articles explaining what PA is all about before and posted similar comments to mailing lists etc.
You can read some of them here:
http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/
and
http://thread.gmane.org/gmane.comp.kde.amarok.devel/15356

I'll outline some of these things here to save you killing my poor server!

More and more audio device *are* network based. Apple Airport Express devices are pretty popular these days. I have two bluetooth headsets and my hifi system also support bluetooth connections and my Playstation 3 supports uPNP. So lots of things relating to network Audio are popping up (which is nothing to do with pulse->pulse network connections which is arguably a toy, even if I do personally use it a lot!). I don't think these should be ignored. PulseAudio supports all of these devices right now (although I've not had time to try the uPNP stuff on my PS3 specifically so don't quote me on that!)

In addition, rights access and management is a big issue. Today any modern linux desktop uses console kit to keep track of user sessions. When you switch from one user to another, console-kit ensures that the currently "active" user session is set to inactive, and it triggers udev callouts to remove the currently active users ACL on the /dev/snd/* nodes. (I seriously hope no one adds their user to the "audio" group these days!). This allows a new user to log in and get access to the sound hardware because they are now the "active" user. Switching between the two sessions triggers these ACL rewrites. Something has to manage this in applications so that they don't just bail out with EPERM errors. The sound has to go to /dev/null automatically without the application being aware of what is going on. Perhaps it can cork/uncork applications that listen for such signals so that music is paused etc. This is something that cannot be done without some kind of userspace daemon handling things.

Then on to power consumption. What most people quite often fail to realise is that Latency is Good. If you can pump 20 seconds worth of audio into a buffer and then switch off until you're woken up 19.5 seconds later then this is great for power consumption. You need to disable hardware interrupts and use kernel level timing constructs to deal with this, and automatically reduce your wakeup time on the event of an underrun to reduce the likelihood of a future underrun occurring. You also have to have accurate timing information reported such that a/v applications can handle things like lipsyncing etc. (and remember that hoping for a low latency audio output is

floating point works fine in my kernel

[r00t]

The FPU works perfectly fine in a Linux kernel. The RAID code can even use MMX, SSE, AltiVec, and so on. Observe:

kernel_fpu_begin();
do_stuff();
kernel_fpu_end();

The same goes for pretty much anything else, Bluetooth included if you actually care.

Even better, in the kernel I can get the ultimate in real-time performance. I can get working fine-grained security like SE Linux instead of crap like that offered by the X server.

Win, win, win. Kernel code rules.

Re:floating point works fine in my kernel

[r00t]

"The FPU works perfectly fine in a Linux kernel."

Uhm. No, it doesn't. The first floating point exception will ruin your whole day.

The kernel has exception handling tables. This is used for a variety of things, primarily access to user space memory. My day is not ruined.

Of course, I'd rather just disable FPU exceptions.

Why would you imagine the kernel includes functions to enable FPU access? You think they would exist but not actually work? Sorry, they work quite nicely.

FYI, I actually write kernel code. It pays well.

"The same goes for pretty much anything else, Bluetooth included if you actually care."

Again, no. You need support from the userspace for Bluetooth.

No. Look, I could eliminate userspace entirely if I wanted to. (it's just a trivial change to not exec init) I can throw pretty much anything into the kernel. The kernel rules all.

"Even better, in the kernel I can get the ultimate in real-time performance."

Wrong. Kernel threads are not any different from the userspace threads.

Um??? They sure are, and I'm not limited to threads. I can use tasklets, softirqs, regular old interrupt handlers, or my own evil invention. I can even disable interrupts if I please.

"I can get working fine-grained security like SE Linux instead of crap like that offered by the X server."

Wrong, as usual. PulseAudio does not depend on the X-server and you can use SELinux just fine. In fact, PulseAudio works under a non-privileged account, so a flaw somewhere in the mixer code won't give the attacker the instant system-level access.

I didn't suggest it required the X server. I said it was the same sort of thing. It's a userspace program that is unable to create hooks for SE Linux policy or get capability bit allocations. Sure, I can use SE Linux as a big hammer, but I can't ask SE Linux to control the internals of non-kernel code.

Re:floating point works fine in my kernel

[Cyberax]

"The kernel has exception handling tables. This is used for a variety of things, primarily access to user space memory. My day is not ruined."

The current treatment of FPU exceptions is 'panic'. Go on, try to persuade kernel people to change it.

"No. Look, I could eliminate userspace entirely if I wanted to. (it's just a trivial change to not exec init) I can throw pretty much anything into the kernel. The kernel rules all."

Go on. Try to read config files from the kernel space, for example. Let's see how far you'll fly when Linus Torvalds kicks you.

"Um??? They sure are, and I'm not limited to threads. I can use tasklets, softirqs, regular old interrupt handlers, or my own evil invention. I can even disable interrupts if I please."

And I can set realtime priority for a thread, which in practice is more than enough.

"I didn't suggest it required the X server. I said it was the same sort of thing. It's a userspace program that is unable to create hooks for SE Linux policy or get capability bit allocations. Sure, I can use SE Linux as a big hammer, but I can't ask SE Linux to control the internals of non-kernel code."

Uhm. But it can. You can't use capability bits, but nobody uses them anyway. Besides, PulseAudio can use _userspace_ authorization system (DBUS + rtkit) which is right now much more usable than anything SELinux people can come up with.

Re:floating point works fine in my kernel

[Cyberax]

"So, what you're saying is, OSS4 doesn't work? I sure hope you don't tell my computers that - they seem to think that it DOES WORK."

So? My old 80386 does work too.

"Seriously - try it, you'll like it."

I tried it and don't like it.

"Oh - bluetooth? Don't own it, can't see the point in it. USB seems to do everything that bluetooth claims to do."

How can I connect my wireless headset to USB _and_ to my cell phone?

Re:floating point works fine in my kernel

[Runaway1956]

I'm afraid you haven't yet distinguished between OSS3 and OSS4. Have you TRIED IT? If not - stop your belly aching. If you have tried it, then put some comments on the OSS4 contributor's site. Since I'm not a developer, telling me how bad it is accomplishes nothing.

Once again, OSS4 solves all of my problems. Sound just works for me, without a hitch.

I have a shorter guide

[jonaskoelker]

http://ubuntuforums.org/showthread.php?t=789578

TL;DR. Here's a slightly shorter guide to a great pulseaudio setup on Ubuntu:

apt-get remove --purge pulseaudio

In my experience it works flawlessly ;-)

Ubuntu is ruining Pulseaudio's reputation

[Per Wigren]

A lot of the problems with Pulseaudio are caused by the misconfiguration of Ubuntu's default kernel. It seems that they will be making the upcoming Karmic Koala even worse, according to a small rant on Lennart's blog today.

Re:Ubuntu is ruining Pulseaudio's reputation

[Entrope]

Lennart gripes in that post about some kernel patches that Ubuntu included -- but his fundamental complaint is that Ubuntu didn't add a different patch, to allow an application called rtkit to put other processes in real-time priority classes. (Running in a real-time class can improve latencies because that app gets to run ahead of most other apps and kernel tasks. A lot of the real-time development on Linux has been driven by audio people looking for more controlled latencies, but that was also before PA.)

In the days of yore, Linux applications didn't need to run at real-time priority to get reasonably good, low-latency audio performance. In days of yore, in fact, they got reasonably good, low-latency audio performance on relatively slow hardware before Linux had anything like true real-time priorities. Please explain to me how PA's apparent requirement to run in a real-time priority class on much faster systems is Ubuntu's fault.

Re:Ubuntu is ruining Pulseaudio's reputation

[Per Wigren]

In the days of yore, people normally didn't run any audio servers at all.

If they did, they either had a lot worse latency than PulseAudio currently has (arts, esound) or they drained laptop batteries much faster than PulseAudio currently do (JACK) or couldn't mix audio coming from different user accounts (JACK). All of them had worse backwards compatibility than PulseAudio.

If they didn't, they could only have one application at a time play sound unless they had one of those relatively rare sound cards that had both hardware mixing and Linux support.

A sound server is by its nature not a normal application. It has many somewhat conflicting requirements that just about no other type of application has to deal with. It's a userspace program that has to do a lot of things traditionally done in kernel space.

As it's very sensitive to timing, realtime priority is optimal but not needed for a usable desktop setup. Ubuntu's default kernel doesn't even have full preemption enabled though. In 2009. Under those conditions you can't run something as timing critical as a low latency sound server reliably.

Re:Ubuntu is ruining Pulseaudio's reputation

[FatherDale]

Maybe so, but while I spent a week trying to make Pulse work with 9.04, it just works under 9.10 beta. Even with Skype.

Re:Ubuntu is ruining Pulseaudio's reputation

[makomk]

Lennart gripes in that post about some kernel patches that Ubuntu included

Not kernel patches - PulseAudio patches. The first patch is complete and utter nonsense - it does an entirely pointless memory allocation and should have no effect whatsoever. The second one changes the default volume control behaviour in a way that's very visible to users for no particular reason.

but his fundamental complaint is that Ubuntu didn't add a different patch, to allow an application called rtkit to put other processes in real-time priority classes.

Oh, they did more than that - they chose to block the installation of rtkit, so even if users manage to install a kernel with the appropriate patch they can't install rtkit to actually make use of it.

Re:Ubuntu is ruining Pulseaudio's reputation

[AdamWill]

"If they didn't, they could only have one application at a time play sound unless they had one of those relatively rare sound cards that had both hardware mixing and Linux support."

Well, to nitpick, this isn't true. ALSA has software mixing support courtesy of dmix, on almost all cards, and most distros used it by default for some time before PA use became widespread.

A legend in its own mind

[Devlin-du-GEnie]

The sound on my =bare metal= install of Fedora 10 didn't work.

After much forum-searching, config tweaking, and pounding-of-keyboard, I eliminated PulseAudio.

The sound worked.

Tell me again about PA's awesomeness.

10 years ago, sound DID work reliably in Linux

[r00t]

That was on 486 hardware and even worse!

The problems started with ESD or esound, the Enlightenment Sound Daemon. Prior to that, sound daemons were unusual. Nobody actually ran one. Enlightenment (the insane game-inspired window manager) got one, GNOME briefly used Enlightenment, and we've been stuck with sound daemons ever since.

The OSS to ALSA transition was the other botch. It used to be that an app just did open() on /dev/audio or /dev/dsp and made sound. Any competant UNIX programmer could handle that. Now we have a kernel API that is essentially unusable, so you have to use ALSA libraries to do anything. Actually, those are **barely** usable.

Really, it wasn't always like this. My 486 DX4-75 with 8 MB RAM (slackware, fvwm-1.x) could handle audio. Back then, programmers didn't fuck around adding bugs and bloat. They wrote stuff that worked, nice and solid, on the hardware that we had.

Re:10 years ago, sound DID work reliably in Linux

[Wonko the Sane]

PulseAudio isn't written for the hardware of 10 years ago. It is written for 2009 where a typical user has multiple independent pieces of hardware each capable of sound input and/or output that may or may not be present all the time (webcams, headsets, bluetooth, etc.)

Re:10 years ago, sound DID work reliably in Linux

[mickwd]

Then why are so many people having so many problems with getting the most basic of these (the sound card itself) to work?

The DESIGN should cope with the situation you talk about, but the (early) IMPLEMENTATION should surely be able to handle the most simple case?

Isn't PulseAudio already on release 0.9.19 or something like that? Surely after this number of releases it can reliably handle the the simple case of dealing with a single sound card?

Re:10 years ago, sound DID work reliably in Linux

[r00t]

10 years ago, you couldn't play two sounds at the same time unless your card could handle it in hardware.

No cacophony? Sweet! Sign me up!

Unfortunately OSS version 4 (part of FreeBSD and OpenSolaris) does mix sounds. It's in the kernel too, so things JUST WORK.

Also, that's about when (IIRC) they started introducing cards (e.g. AC97) that could only two one or two rates or (in some cases) could only do stereo. The driver would simply refuse to handle mono or 8 kHz so you had to resample by yourself.

OSS 4 resamples too. FWIW, the old OSS did stereo and fast rates if you used an ioctl to request them or if you opened /dev/dsp as the device.

computers are hard

[Deanalator]

Sometimes mplayer will have sound, and totem will not, and other times, the opposite is true. Since the switch to pulseaudio, I have never seen a time when they both worked. Just a half hour ago there was no sound in miro. The volume slider in miro was turned up, the system volume was turned up, and my speaker volume was turned up. When I right clicked on my sound icon, went to preferences, and flipped to the "applications" tab, I found yet another volume slider labeled "miro" that was turned all the way down.

A few months ago I bought new speakers and a new sound card because my sound stopped working. The new hardware still didn't work, and a few days later, I found some random profile or device or something that was muted, but to even see that menu I had to change the default device in some gui I had never seed before, and then change it back. Starting about a month ago, whenever I play a youtube video, sound will not work for anything but flash (even after I close firefox) until I killall npviewer.bin

For some reason, when "surround" is muted on my laptop, my headphones don't work, but everything else does like normal, and if PCM gets muted, I will only get sound back if I turn the volume all the way down for a second, then turn it back up. Also, my USB headphones and USB speakers have never worked in linux.

The new surprises with every upgrade is also pretty fun. It used to be that I could just do a killall "pulseaudio" then /etc/init.d/alsasound restart, and everything would be back to the old way of working, but recently it just breaks everything even worse, requiring a reboot to fix. I'm hoping that a clean wipe of everything, and installation of ubuntu 9.10 may magically fix some of these random idiosyncrasies, but I'm not holding my breath for it.

Programming in general, is a lost art for Linux

[petrus4]

I've looked at GNOME, I've looked at ALSA, (indeed, Ubuntu in particular in general terms) I've looked at the bloated instability of Compiz, I've looked at FreeBSD by comparison, (which I use on a daily basis) and at some of OpenBSD's source...and I've come to an important realisation.

When it comes to both design philosophy and code quality, Linux developers suck; and I'm talking black hole level, here. The BSDs leave Linux so far behind that it isn't funny.

What is even worse than the poor code quality, is the level of denial. The GNOME developers in particular have been told on numerous occasions what an abomination their baby is, yet they continue to insist on defending it, rather than actually listening to the feedback they are given, and trying to improve.

The single main problem is what I called the Starbucks generation; self-righteous, latte-sipping yuppie CS graduates, who as said in another post, worship C++ and various hell-spawned forms of RPC, and use such to code bloated monoliths of a magnitude that would give Microsoft nightmares.

They think they know better than the 30 years of UNIX experience that has come before them, including the very authors of the initial operating system itself.

Although I haven't used Pulse, I have used ALSA, and I've used enough other Linux software to know that the Pulse author most likely shouldn't be defending himself; but should be humbly acknowledging that his software is terrible, and appealing to the community for help and insight into how he can do better.

He can start by reading this, and gaining a real appreciation of the system he is writing for.

There are a lot of programmers in the Linux community who badly need some humility. They need to study the designers and authors of early UNIX; they need to learn how those people thought, and they need to emulate said designers' thinking and behaviour.

Above all, more than anything else, there needs to be a return to implementation, rather than interface, simplicity. As priorities, faddishness, popularity, and most of all, the end user, need to die.

Re:Programming in general, is a lost art for Linux

[jimicus]

There was some article on /. only a couple of weeks back about how communication is important in the real world and the general tone of many replies was "No it isn't".

The fun bit is (and I'm sure it was unintentional), you've just proven the point beautifully. For example:

The GNOME developers in particular have been told on numerous occasions what an abomination their baby is, yet they continue to insist on defending it,

If the criticism is being levelled in those terms (and my own experience suggests it probably is), I'm not surprised. How many times in the whole of history has criticism in those sort of terms ever resulted in the person you're criticising looking back over their work and saying "You know what? You're right."? This is basic animal instinct - the natural response to an attack is defence. It sure as hell isn't a natural response to consider the attackers' perspective and think maybe they have a point.

Re:Programming in general, is a lost art for Linux

[Thalaric]

Wow, you managed to hate on Alsa, Linux, Gnome, C++ and the End User all in one post. Condolulations, this may be the most faddish post I've ever seen.

Re:Programming in general, is a lost art for Linux

[turing_m]

As priorities, faddishness, popularity, and most of all, the end user, need to die.

Are you serious? Faddishness, I agree with. Popularity - popularity is something worth considering. Popularity implies community, and with a large community chances are most elements of a given problem have already been coded by someone else. Consider Perl and CPAN - a good reason to use Perl. But popularity is not enough to make me choose MySQL over PostgreSQL for instance.

Lastly - the end user as a priority needs to die? That really depends on who you are writing the software for. If it's an operating system and you want it to compete with a Windows or OSX on some level, considering the end user is unavoidable. A vastly larger feature set and complexity than say, OpenBSD, is also unavoidable. Lack of time to audit the code and remove bugs to the degree that OpenBSD has done is also unavoidable. Maybe this goes some way to explaining the quality of the code and the size of the user base of both operating systems.

Re:Programming in general, is a lost art for Linux

[u38cg]

You know, maybe you have a point. Asshole.

Re:Programming in general, is a lost art for Linux

[petrus4]

After reading your comment I don't know which BSD Desktop Environment I should look at to see comparable code that is higher quality

Enlightenment is BSD licensed. That wouldn't be a bad place to start.

I've already spoken numerous times about GConf, as a major element; about how I can't (as one example) install Firefox without installing GConf and all of its' subsequent dependencies, because I'm not able to specify a GTK theme via dotfiles any more. There are also reports now of GNOME, on Ubuntu at least, beginning to emulate the famed winrot or registry creep effect that we all knew and loved so much with Windows.

Then, just for shits and giggles, let's list a suggested build order for Gnome 2.6.

* libxml2
* libxslt
* gtk-doc
* glib2
* libIDL
* ORBit2
* intltool
* libbonobo
* fontconfig
* Render
* Xrender
* Xft
* pango
* atk
* shared-mime-info - download
* gtk+
* gconf
* gnome-mime-data
* gnome-vfs
* esound
* libgnome
* libart_lgpl
* libglade
* libgnomecanvas
* libbonoboui
* hicolor-icon-theme - download
* gnome-icon-theme
* gnome-keyring
* libgnomeui
* startup-notification
* gtk-engines
* gnome-themes
* scrollkeeper
* gnome-desktop
* libwnck
* gnome-panel
* gnome-session
* vte
* gnome-terminal
* libgtop
* gail
* libgail
* libxklavier
* gnome-applets
* metacity
* libgsf
* libcroco
* librsvg
* eel
* gstreamer (make sure you have libraries for any audio codecs you plan to use isntalled)
* gst-plugins
* nautilus
* control-center
* libgnomeprint
* libgnomeprintui
* gtkhtml2
* libgtkhtml
* yelp
* bug-buddy
* gtksourceview
* gedit
* eog
* ggv
* file-roller
* gconf-editor
* gnome-utils
* gal
* gnome-system-monitor
* gnome-media
* nautilus-media
* gnome-netstatus
* gcalctool
* gpdf

Could you get sound from multiple sources?

[Sycraft-fu]

One problem that many forget looking back on the "good old days" of sound is that you couldn't get sound from more than one thing. On single task OSes like DOS this wasn't a problem, you only ran one app. However for multi-tasking OSes it meant that whatever opened the soundcard first had control until it gave it up. This was problematic for many reasons. Meant that you couldn't even do something simple like play an alert sound from the OS if someone was playing MP3s (not such a problem in the 486 days since those were hard pressed to decode MP3s in realtime).

Well, that's where sound daemons come in. The OS mixes sounds from multiple apps and sends it to the soundcard. Thus you can have multiple programs using sound, just like video. What's more, it'll let you do things like control the volume if an app neglects a volume control. Firefox doesn't seem to have a volume control, but the Windows 7 mixer has no problem adjusting its volume, independent of the system.

There is no reason why this should be a problem. Windows and OS-X do it just fine. There is a sound layer the OS has that you write drivers for an all apps can interface with. You can extend/bypass that with your own APIs if needed (like OpenAL or ASIO). It works really well. For that matter on Windows now they have created the concept of Universal Audio Architecture which is a standard way for devices to expose their functions to Windows, and thus work without device specific drivers.

There is no reason Linux can't do this as well. You can have an audio daemon, and should. What need to happen is time send to be spent designing things in an intelligent way first, and then implement them so that they don't change all the time. Have a standard ABI that the driver writers develop for, and a standard API(s) that the software developers write for. Have standard mechanisms for people to add to or override that if needed.

It'll work fine, if designed well, implemented well, and not fucked with. You can't change the spec every other week. It needs to be laid out and stuck with.

This isn't theoretical, as I said OS-X and Windows do it, and have been doing it for some time.

Re:Could you get sound from multiple sources?

[TeknoHog]

ALSA handles multiple sources well enough by itself, with the dmixer plugin.

I imagine sound servers may have some legitimate uses, but for the software mixing, I don't see any reason why most users would need anything beyond plain ALSA. Thus it seems like a bad idea to run a sound server by default.

I also use plain ALSA for making music, and when I play around with multiple sound cards, I want to set things up as directly as possible. The dmixer plugin is easy to bypass.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Article is doomed to failure, but PulseAudio is

[ardor]

Latency is Good

No its not. Video playback with an audio lag of several seconds? Not good. Playing games with an audio lag of several seconds? Not good.

As for the networked audio stuff, you mention UPnP. All you need for UPnP to work is a dedicated UPnP server like Mediatomb to stream your audio to the client. You do NOT need an audio daemon for this.

Re:It may be buggy...

[Entrope]

The funny part is that if you have what the 99.9..% want, accessed through a reasonably thin shared library, it becomes pretty easy to forward it over a network. You end up with higher latency, but PA certainly seems to be putting the cart before the horse.

Re:Article is doomed to failure, but PulseAudio is

[Entrope]

A lot of devices stream data over a network and play it locally as audio. That does not necessarily make any of them a "network based" audio device in the sense that they can be driven by PA.

Audio is not unique in needing device ACLs adjusted; it should not need a unique solution for doing that. In fact, having an audio server handle ACL adjustments when something else does that is a violation of the Unix philosophy of chaining together simple tools that focus on one thing.

Application-controlled latency is good. Library-enforced latency is bad. Sending audio from one user-space process to another is a case of the latter.

After reading your post made "as a PA developer", I'm even more down on it than before.

Re:Or yes

[f0rk]

It's all about keeping the issues list organised and neat.
Some of your stuff wasn't related to PA, so he told you were to file them.
Some of your stuff was duplicates, so he told you were to discuss that, so he and other people could help you out, and in the long run get a more stable system released.
Some of your stuff was already fixed, so he told you that it would most likely get included in an update of the next major version of your distro.

Think about it, he might have a lot of issues he has to keep in organised. Having ONE "issue" with several unrelated problems will make it a hell to try and fix. The inconsistent flow of unrelated comments and discussions would only make it worse.

I don't think there is even one large open source project that excepts multiple problems as one "issue", and would most likely respond in a similar maner.
Some project take it even further and replying "File separate issues. Closed."

This is a "problem" with the open source community as whole, and not with Lennart (or any one else) ignoring your reports.

Re:Benevolent dictators

[zach_the_lizard]

Mark Shuttleworth shaped Ubuntu up to be the ONLY decent desktop linux distro

Flamewar starting in 3....2....1....

This is why we have Macs

[mikelieman]

I believe the solution to any *PROFESSIONAL* Linux Audio Production issue is to just go buy a Mac.

Re:Article is doomed to failure, but PulseAudio is

[advocate_one]

And as I said, most applications seem to have this built in concept of "latency == bad", which is just bogus in most cases (media players etc.). If power consumption is the main factor (and with handhelds, laptops, netbooks and the like, it frequently *is*), then latency == good. Fewer CPU wakeups, longer battery life. Intel and others have been experimenting with large latencies of about 10-20 seconds with good results on power savings.

latency sucks... If I play a note on my guitar or keyboard, then I do not want to hear the sound more than a couple of milliseconds late... this is precisely why I still do my music recording on a windows box... I still can't get rid of it much as I really want to... I did have a perfectly good Ubuntu Studio setup going back on the LTS (Dapper Drake) before the current one, but certain issues pushed me into upgrading to the next LTS (Hardy Heron) and boom... pulseaudio screwed it all up... I was completely dumbfounded when I discovered it was an experimental sound system just dumped into the LTS without any attempt to get the default settings correct. I expect the LTS version of Ubuntu to actually work out of the box. So as a result, I got my XP box out of mothballs and went back to using XP for recording.

Re:Article is doomed to failure, but PulseAudio is

[QuoteMstr]

No its not. Video playback with an audio lag of several seconds? Not good.

You're confusing synchronization and latency. There's no particular reason you can't buffer up a few seconds of audio, yet make sure that audio is played exactly when the video calls for it.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

"next LTS (Hardy Heron) and boom... pulseaudio screwed it all up..."

Dude, Ubuntu's integration of PA in that version totally sucks. They didn't even try to get things right there and this then reflects badly on PA. Ubuntu have made a *lot* of mistakes with pulse and are continuing to do so, so please don't use this as the benchmark to judge.

We released Mandrvia around the same time with our first PA-by-default version, and it was received very well. So don't blaming the carpenter just because the stable boy left the door open while the horse bolted.

Ugh, Yea, Pulse sucks

[Urza9814]

I was using PulseAudio for a while. Every time I booted up I'd have to manually restart pulse. Then one day it just stopped working entirely. So then every time I booted I'd have to manually stop pulse and start alsa. Then that stopped working entirely. Finally I just completely removed PulseAudio, and everything has been working perfectly ever since.

Re:Article is doomed to failure, but PulseAudio is

[Entrope]

The point of my first sentence is that it's stupid to point at the PS3 or Airport Express and say "that's like PA's network support!" because they work quite differently. They send almost arbitrary audio files over the network; PA sends audio bit streams.

The point about ACLs is precisely that it should be centrally managed. If PulseAudio is applying its own policies independent of the other ACLs that get adjusted when I start a session, it's wrong.

So you have a buzzword compliant core. Are there any copies from application buffers to device buffers, or vice versa? How does it select output block sizes, for the kind of low-latency things that advocate_one is talking about? How does PA handle output stream mixing between applications? (Maybe it doesn't -- MPlayer on my machine is unable to open the audio device if I have a browser open that ever looked at a YouTube video. If it worked, that's a feature I would use a lot more than dynamically switching an audio stream between devices. It worked fine under ALSA.)

PulseAudio is broken

[OverflowingBitBucket]

I've had three systems with audio problems. Two Ubuntu-based (8.04, 9.04), a third OpenSuSE-based. All with PulseAudio. All had oddities- ranging from the sound working only during X session startup/shutdown (and not in-between), through to the audio skipping, repeatedly, when changing the current desktop. These were on reasonably decent machines, by the way. Machines that should gobble up and spit this data so fast that it barely dents CPU usage.

In each case, disabling PulseAudio and using, well, anything else, caused the problem to go away. OSS, ALSA, didn't matter, they both worked. Sometimes it was easy to remove PulseAudio, and sometimes it took a bit of work. Ubuntu 9.04 was a challenge. No, scratch that, it was a fight.

I look around, I see horror stories and widespread problems with PulseAudio.

I see claims that it works, if you configure it "properly". You know, I heard the same vague defence regarding Windows' instability. I didn't believe it for Windows either.

I've heard that PulseAudio has a great set of features. However, I have no interest in digging into what these features might be. The core feature that I want above all else isn't supported by PulseAudio. That feature?

Playing seamless audio.

PulseAudio can't even get that right. Stutters and skips are the norm, audio systems that worked previously no longer do, and the backers of this abomination are in abject denial about it. There are widespread complaints about it across multiple applications and multiple operating systems, and still it "isn't configured properly". You can't be serious. Complaints about PulseAudio are not really shared by the majority of technical people? Oh, yes they are.

If you want to provide a reasonable sound system, a *core* focus has to be on providing a working sound system. Get the core functionality right, then move onto features. Stability, correctness. Get the basics right. Also understand that API users may stuff things up, and falling over and dying is not the correct thing to do. The infrastructure needs to be resilient, not fragile.

PulseAudio did *not* do this. Any of this.

The order of the day seems to be to blame everything *but* PulseAudio. The apps are broken, the drivers are broken, the operating system maintainers didn't integrate it properly, it's not configured properly for the user's machine, the people complaining wouldn't be complaining if they were more technical, a lot of distros have adopted it so it must be good. Did I miss anything here? This has been the argument thus far.

I'm going to be different. I'm not going to blame the developers, the applications, the users, the knowledge of the users, the operating system developers, or anyone else. I'm going to blame the one at fault, the *cause* of these problems. The one thing in common with this incredible list of problems.

PulseAudio is completely and utterly broken- in design, in implementation, and in application. It is horrendous, shameful, and embarrassing.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Dude, I'm not talking about lag, I'm talking about latency. Latency is the time it takes from inserting the data into the buffer for it to be heard. Lag may be bad, but high latency is certainly good.

Mediatomb is a deamon in itself and it's a totally different use case than the UPnP support in PA, so please don't compare apples to oranges.

Re:Article is doomed to failure, but PulseAudio is

[_merlin]

There's no particular reason you can't buffer up a few seconds of audio, yet make sure that audio is played exactly when the video calls for it.

Yes there is: you don't want to be playing a game, and only seeing responses to your inputs seconds after you do things. Any noticeable input lag in a game ruins the experience. Ideally, you want no more than one frame of latency between reading inputs, running an iteration of your engine and getting it out to the display/speakers/haptics. Not all content is pre-recorded.

Re:Article is doomed to failure, but PulseAudio is

[QuoteMstr]

One of the nice things about PulseAudio's design is that it allows you to combine large buffers for some tasks with very low latency for others.

PA configures the audio hardware to the largest playback buffer size possible, up to 2s. The sound card interrupts are disabled as far as possible (most of the time this means to simply lower NFRAGS to the minimal value supported by the hardware. It would be great if ALSA would allow us to disable sound card interrupts entirely). Then, PA constantly determines what the minimal latency requirement of all connected clients is. If no client specified any requirements we fill up the whole buffer all the time, i.e. have an actual latency of 2s. However, if some applications specified requirements, we take the lowest one and only use as much of the configured hardware buffer as this value allows us. In practice, this means we only partially fill the buffer each time we wake up. Then, we configure a system timer to wake us up 10ms before the buffer would run empty and fill it up again then. If the overall latency is configured to less than 10ms we wakeup after half the latency requested...

GStreamer?

[Doc Ruby]

Whatever happened to GStreamer? I thought that "circuit/pipeline" model for building audio systems would make it easy for developers, and foster a whole new generation of interfacing audio to apps, and people to each other by audio. Where did that catchy future go?

Re:Article is doomed to failure, but PulseAudio is

[_merlin]

That's the biggest load of crap I've seen. So it uses system timers and its own buffer management? That's sure looks to me like an overly complicated way of trying to get around poor primary interrupt latency in the OS kernel.

(That's one thing Apple got horribly wrong with MacOS, but fixed properly with OSX. MacOS didn't have predictable interrupt latency, and running any real-time applications was asking for trouble. How Avid, DigiDesign and Opcode succeeded is beyond me. However, OSX has the best primary interrupt latency of any OS right now, and the best audio stack. I really wish someone would leap-frog them to give them some incentive to make it better.)

Re:Article is doomed to failure, but PulseAudio is

[LizardKing]

It's [PA] structured the same way the audio systems on Windows and OS X are.

Like hell it is, and I say that as someone who has programmed audio and MIDI apps for OS X, Linux and NetBSD.

There should be no such distinction. Any "lower level" API should be an implementation detail of the application-level audio system, just as the PCI configuration space is an implementation detail as far as X clients are concerned. As for the traditional distinction between the audio deamon interface and the "lower level" one: it's an accident of history that we lived with that split so long. PA is a better world.

Last time I checked, PCI configuration was not time critical. As for the "accident of history", fact is you've got too much functionality in userspace.

As for POSIX real time scheduling? Just because the API exists doesn't mean it's implemented or configured on any of the major distributions, as it requires patches to the regular Linux kernel that would be detrimental to most peoples requirements. And my comment on switching users is no more anecdotal than Poettering's unsupported assertion that PA does what most users want.

Re:Article is doomed to failure, but PulseAudio is

[RiotingPacifist]

Then on to power consumption.

Why is this being done by PA not by ALSA? It really seams this should be implemented in ALSA not in a userspace tool

OSSv4 or older flavours simply does not have the API to deal with a modern linux desktop

Instead of getting into flamewars over APIs, could you explain why OSSv4's API can't handle the modren linux desktop.

...it really wouldn't be a proper solution (and guess what? it would need a daemon running anyway!!)

Audio APP->kernel-> seams like a nice solution, then IF something needs to be pushed back out into userspace, do it
Audio->userspace->kernel just adds more problems for 90% of users, it makes sense to me to have audio->kernel->userspace->kernel when required, the 10% that regularly use stuff that needs userspace action configure it themselves (much like people install jack if they need it).
One final point regarding APIs. Why should the standard API cover stuff like position dependent events when this could be handled by a wrapper/app?

More and more audio device *are* network based.

Then there is the whole concept of thin-clients.

Most users don't care, we've simply gone from something that worked to something that doesn't, but generally speaking most desktop audio is coming out of the speakers, this path should be a priority and if that means stuff gets a bit uglier for these devices/setups so be it. If the only way to handle them while keeping desktop audio sane is too ugly then the people that use these devices should configure PA when needed (or hal should), so that 90% of the time desktop audio (usually single app(+random event sounds)->speakers) is as simple as possible.

Then of course there is the mixer.

This is partly inherited from alsa but dear god do audio devs not understand that 0 = mute? If you must have an infinite scale then don't tell me my audio is at 0!

PulseAudio as an architecture is fast becoming the defacto standard

Terrible argument as soo many de facto standards suck. (not that it matters but de facto is two words, much like de jure)

In addition, rights access and management is a big issue.

I think this is a major strength of PA, however I am the only person that uses my desktop and when I switch to a root TTY I still want to listen to my audio alerts, is there an easy way to disable this feature. (e,g the bug that existed in alsa was a feature not a bug)

You've probably being using a distro that doesn't care to integrate PA properly

Funny i use Fedora, which AFAIK has it's PA maintained by Lennart, yet it still has many problems.

p.s thank you for the informative posts, while I disagree with parts of PA i do appreciate it and can't stand the level of FUD around it.

Use pinfo to read info pages

[Mark Shewmaker]

Ah, documentation. On linux, most entries in the online reference manual (`man pages') send you off to *censored* info requiring a *censored* "info viewer" that expects you to know emacs and two to one will give you the manpage again only this time you need *censored* emacs contortions to get out of dodge.

Use "pinfo" to read info pages: apt-get install pinfo

pinfo is the opposite of "info" in almost every respect:

1. It's simple to use. No contortions necessary. (Use arrow keys and "q").
2. Color highlighting makes the info pages easy on the eyes.
3. Arrow-up and arrow-down moves you between highlighted and very visible info-hyperlinks within the document, without the need to visually hunt for special "::"-delimited links.

And as a bonus, you can use it to read man pages too:

1. If there's no info page, it will show you the man page instead.
2. If you want to read a specific man page when there is already an info page, use syntax such as "pinfo -m 2 mount" versus "pinfo -m 8 mount" to read the section 2 versus section 8 man page. (This is nice if you want to pretend you're in lynx and select one man page from within another, or select a web page from within a man page.)

I disagree

[Sycraft-fu]

In terms of playback, the digital side of things should be limited such that it can never clip out. Digital clipping sounds extremely bad, and can damage speakers if it happens at high playback levels. Your computer should function such that 100% on the volume slider is equivalent to 0dBFS, no attenuation. All volume should be attenuation only in the digital domain.

So how do you make things louder? Turn up the volume on your amp. Computer speakers have a volume dial, receivers have a volume dial, etc. Use that, control the volume on the amp, not the digital levels. People shouldn't have to worry about setting their controls such that it results in digital clipping.

Re:I disagree

[adolf]

Eh?

In my computer room, I have an amp and some speakers, plugged into an X-Fi card. It's just an amp, though: There's no controls on it whatsoever except for a power switch. Voltage goes in, gets amplified, and heads out toward the speaker jacks.

On the X-Fi, I've got all the control I need: Parametric EQ, volume, and...well, that's about all I use. I don't need nor want an extra set of controls (and associated electronics) to muddy up my sound, and I don't want to make room on my desk for such a contraption, either. Thanks.

With Windows, I can turn up quiet things just fine, using the just the Audigy as a preamp. With PulseAudio, I can't. And as more than one other poster has already pointed out: This is also a problem on a laptop, where there's simply no practical way to insert an additional amplification stage before the speakers.

Positive gain in the digital domain is very common in consumer audio: Your car stereo, if it is anything modern, offers it. So does your home theater receiver if it is at all recent. Get your head out of the sand. The world isn't perfect, and we sometimes need gain to make good use of existing audio hardware.

Besides: Clipping ANY stage of an audio path sounds bad, and can damage loudspeakers. It's not at all a new problem, having existed since the dawn of the Hi-Fi. Back in my day, we used our ears to tell when things were being pushed too hard in one area of a system or another, and turned things down when appropriate. Meanwhile, I don't need a computer to hold my hand and tell me that I can't turn something up when it is simply too quiet to be useful.

Re:I disagree

[Blakey Rat]

Ladies and Gentlemen!

See here the man who is unaware of the existence of laptops! Yes, this sad specimen of a Slashdot poster actually believes that all computers have external speakers and amplifiers plugged into them at all times. The thought of using a laptop to play a funny YouTube clip during a break in a meeting has never occurred to this being! Fear him, and pity him!

Re:Article is doomed to failure, but PulseAudio is

[mhenley]

PA is not designed for being used when you are recording and need low latency. Lennart will tell you (and has told me) to use JACK for recording situations where you can set the system for ridiculously low latencies. I do not want to be seen as defending PA (I think it was released to the masses long before it was close to the level of functionality of its predecessor) , but the devs have been working recently to make PA play nicely with JACK. When I start JACK, PA releases those devices and I do my recording, When I finish, I stop JACK and PA takes them over again. Its not perfect yet, but its working for me. I have my Zoom H4 usb microphone as audio input, usb midi for keyboard input and the ALC888 as the audio output and it works fine with no discernible lag for me. Still need to compile a reatime kernel, but thats next week. Matt

Don't want to join the bandwaggon...

[McNihil]

but I do have to say that Pulse Audio... well I have nothing good to say about it. OSS worked for me back in the day and I rarely had any issues. ALSA worked for me after some fidgeting but things got stable quite fast. Pulse Audio.... nothing but trouble since Fedora 9 and onward. Is it getting better? Possibly it is, but on all machines that I have used it on it always becomes excruciatingly painful with its odd volumes and.... ok I feel a rant coming along here and I don't want to really diss anything that I didn't actually pay for. But daym... I do have to say that if the rest of GNU/Linux was done this way we would not be here today PERIOD.

Re:Article is doomed to failure, but PulseAudio is

[jhol13]

If JACK can handle low latency and it works, what is the point of PA?

The only case where latency does not matter is media player ... and then only when the media is audio, and even then there are limits (~200-300ms max). Video must be pausable and seekable - without delay. VoIP is killed with 50ms delay as the codec will create additional delay.

Adobe's Linux sound bitching

[Tetsujin]

An interesting side note on audio APIs: http://blogs.adobe.com/penguin.swf/linuxaudio.png

Man, not that bullshit again...

Let's break this down.
First you have platform independence layers - things like ClanLib, SDL, libao, PortAudio, Allegro, and Open AL. These would be present on any platform. That's the point of them. The diagram seems to go out of its way to mix these in with lower-level technologies, as if to make it less obvious that they're just included to pad out the diagram.

Then there's the trio of obsolete network audio servers: NAS, ESD, and aRts... I suppose if I were to fire up a quick game of xpilot then I might want NAS, but otherwise one can usually assume these days that these three servers aren't installed and don't need to be.

There's FFADO - which is relevant if you're using a firewire audio device... How many people do this? I guess it could be popular among musicians and sound techs - have audio hardware outside the computer's case, accessed via a bus that isn't USB... But this is a driver layer, not an API layer - and these days it seems FFADO provides an ALSA interface, so I think the complaint here is obsolete.

That leaves three modern sound servers (Jack, Pulse, and GStreamer) and two low-level APIs (Alsa and OSS). This is still a bit of an unfortunate mess IMO but nowhere near the rat's nest implied by the diagram.

Ok, call me when it's ready

[sean.peters]

While I fully understand you being annoyed that your current distro/version ships with a default configuration that isn't fully adjusted to this very common usage pattern, it also means that the situation will get better as distributions learn how to properly integrate Pulseaudio and the remaining bugs in Pulseaudio itself are fixed and it gets better at automatically detecting and adjusting to different hardware setups.

Look, I understand that getting this stuff right is a hard problem and takes some effort to get resolved, and that' s not necessarily the fault of the developer. But it's not my fault either. I don't have time for this kind of thing - while there was a day when I really enjoyed spending a bunch of time fiddling around with my computer to get it to work right, those days are mostly over for me now. I need sound to "just work", and if Pulseaudio doesn't, then I'm not using it.

Difference with FreeBSD?

[ottdmk]

Hi all... FreeBSD user, not really a Linux guy. What's the difference between our sound system and Linux, anyways? IIRC we're based on Open Sound System, but I could be mistaken. Sound still isn't configured by default in FreeBSD, but it seems to work quite nicely once the right kernal module is loaded. I can have any number of sound-using apps open. They all open /dev/dsp and get their own sound channel. Anyways, just curious is someone who's familiar with both OS's can fill me in. This conversation has been really interesting.

Re:Difference with FreeBSD?

[petrus4]

Hi all... FreeBSD user, not really a Linux guy. What's the difference between our sound system and Linux, anyways?

The difference between Linux and FreeBSD in terms of audio, is the same as the difference between Linux and FreeBSD in general terms.

Namely, that FreeBSD is developed by adults, who know what they're doing. As a result, things in FreeBSD generally just work, without fuss.

Re:Article is doomed to failure, but PulseAudio is

[segedunum]

What specifically about PA's buffering scheme doesn't make sense? It provides for low latency (especially when the PA daemon itself runs with realtime priority); it saves power;

The problem with PA's low latency set up is that it consumes and inordinate amount of CPU. Lennart has admitted that. The problem with sound servers doing too much is that they will inevitably add latency. Paradox.

Re:All you really need to know

[petrus4]

PulseAudio isn't perfect, but the basic ideas behind it are sound, which is why the whole Linux world is adopting it.

I call BS, here.

Things don't get adopted by Linux distributions because they're technically sound; they get adopted if, for whatever other reason, they become the fad flavour of the month.

I tried for nearly two months to use Ubuntu Intrepid Ibex; audio was dying constantly, and I was having kernel panics randomly from the video card drivers as well. Then there was the nightmare when I made the mistake of trying to use another window manager beside GNOME.

Linux in technical terms is crap, currently, and I'm fed up with the denial. I'm using FreeBSD, and have been since January; I wanted to use Linux, but aside from maybe Slack, Arch, and LFS, none of the major distributions are usable without giving me endless problems. It's either package management, or hardware drivers, or the DE is fused with everything else and can't be removed, etc...it's hell.

Stop claiming things are fine when they're not. Stop writing propogandist garbage like this, where you're basically just trying to force people to hold their noses and drink the Kool Aid, when they're telling you in droves that real problems exist.

The denial needs to stop, and the problems need to be acknowledged and fixed.

* We need a sound daemon that doesn't try and have a heap of other features which hardly anyone ever needs, but that just plays audio. THAT'S ALL IT NEEDS TO DO. No client/server crap. No being able to play files while changing the sound card. None of that shit. All it needs to do is play audio files.

* GNOME needs to be scrapped entirely, and replaced with something that isn't committed to simply reproducing all of Windows' design mistakes. We need a window manager that is genuinely designed according to the UNIX philosophy. That means dotfiles for configuration, not a centralised registry which just bogs everything down. It also means use of the pre-existing sockets system for IPC; NOT abominations like XML-RPC. It also means something which is genuinely modular, not where if you install any one single piece, you then HAVE to install all of the rest.

* Init/Upstart both need to be scrapped, and replaced with FreeBSD's init system. It is simple, clear, sane, and WORKS.

* Ubuntu's insane mess for kernel module loading also needs to be annihilated as well, and the standard module loading programs need to be used.

* This is something which I know will never happen, because Canonical are too stupid and delusional, but if they truly were intelligent, they would drop Debian as a base. They need to use something cleaner, like Slack, Arch, or LFS, and they could then save a lot more work for themselves by adopting pkgsrc (which is being maintained by NetBSD) as their package management system. Ports systems are a lot more robust than dkpg/apt, and I don't want to hear the contrary from the usual Debian fanboys, either. YOU ARE WRONG, and Ubuntu's upgrade routine trashing systems is the proof. For ONCE, sit down, shut the hell up, and accept it.

If you really mean any of the talk that you keep endlessly engaging in about wanting to be competitive, Linux community, then fucking lift your game.

The first step to doing that is ending the denial, once and for all. The second is to cease mindlessly aping Windows, and establish your own identity; ideally one based on the very UNIX design principles that you've been so enthusiastically throwing away.

Let's see how many of the Generation Y, amateur, snot nosed brats I get making a response to this post; people like the idiot who wrote the post that I'm replying to, here. People who think that everything with Linux is just fine, and who continue churning out bloated, inefficient, unstable crap, because they don't know how to do everything else, yet still see themselves as an avatar of Neo inside their own heads.

Mod me down, instead of refuting me, as well. Use every lame Slashdot trick in the book for posts you don't agree with.

This is the truth, Linux developers. You might not like it, but you need to fucking hear it.

Re:PulseAudio sucks!!!

[cuby]

Yes... Pulseaudio doesn't see the S/PDIF output used to send audio to the video card.

Re:All you really need to know

[petrus4]

I see two possibilities here. Either you are just trolling, in which case shame on you for wasting our time; or else you really believe all this ranting stuff you wrote, in which case you need to gain some technical maturity.

Except you're not going to be any more specific here, are you? You'll call me immature, but you don't define what maturity means in that context.

I'm by no means the only person who has had problems with Ubuntu; if you think that, you might want to hang out on their support forums sometime.

And you don't offer any facts or even reasoned debate about any of this.

FFS; I keep hearing this over and over again, too. Go and look at my comment history. Read the comment I made there, only about two posts ago, about exactly what is wrong with GNOME. No, I'm not going to write all of that out again.

You asking for more and more and more "facts," is also BS. The only thing you're really asking for is ammunition that you can use to refute me, because on a completely emotive, subjective basis, you don't want to listen to me at all.

You don't understand why PulseAudio is designed the way it is, therefore it must be the work of an idiot, and anyone who defends it must be an idiot.

I understand that Pulse has a lot of features in it which it doesn't need, for the purpose of playing audio files. The other stuff might be nice, but there's a difference between something being nice, and something being necessary, especially if it doesn't work.

Regardless, this is yet more denial. There are so many people using and writing for Linux who think that the way things are done with it, is the only way things can or should be done, and what that usually translates to fairly directly is imitation of Microsoft, as closely as possible. Hence, when excessively, needlessly complex, bad software is written, you keep defending it, because you don't know any better, and you also falsely associate Microsoft's own history of writing bad code, with their popularity. Which, of course, leads us back to the real heart of the problem.

Attempting to achieve mainstream popularity at virtually any cost, is the only thing that Linux developers really care about at this point. Technical integrity or correctness don't enter into the discussion at all; or when they do, it's even worse. You've redefined what technical integrity means in your own heads, such that said definition always leads back to what will simply make Linux more popular. Not what is conducive to actual stability or efficiency with the system.

Re:All you really need to know

[petrus4]

What would be the point of that? FreeBSD is doing a good job of being FreeBSD. You like it, go use it and stop ear-bashing.

Translation: "FreeBSD works, and you want something that works, you say? Then go use FreeBSD. With Linux, we continue to support elitist incompetence. When critical operating system infrastructure doesn't function, we don't fix it; instead we make excuses for the developers who are responsible for the mess. We also try and humiliate and/or discredit users who complain about this state of affairs, and tell them to stop being such big meanies.

We also insist that we know better than the authors of the initial UNIX operating system, even though their software worked, and ours doesn't."