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

[stonefoz]

I wish I had mod points. It's not offtopic, at least I think it's funny. Have you seen pa go wrong?

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

[spyder-implee]

Haha, nice. I lol'd! Thank you!

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

[hamanu]

Whoops, meant to say "instead of /etc/init.d/oss" during init.

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

[Runaway1956]

That is interesting. If I find some time (before I forget about this thread) I may do some experimenting. Mostly though, I don't need or want sound, so I have a set of USB headphones lying on top of the tower. I only grab them when I want to listen to something. But, this does look interesting enough to play with. I'll have to steal my speaker system back from the kids if I do play with it. ;^)

Re:This is the Sound of

[hamanu]

There may be additional hacks you need. Specifically comment out the lines in soundon or whatever they called it that uninstalls the alsa drivers, or you'll have to re-install the kernel after it deletes them. And be aware you may have to strangle udev to get it to STOP LOADING THE GODDAMN ALSA DRIVERS FIRST.

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]

In Soviet Russia Pulse kills YOU!

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

[mister_playboy]

A speaker is usually just a passive device that reacts to the load it is fed. There are some nice speakers that have a protection system, typically for the tweeter.

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

[electrosoccertux]

Turning the volume louder than the total of 0db demolishes your speakers

No it doesn't. A speaker gets a signal and that's all it needs. Loud signal has higher amplitude.
The crackling you're hearing is your cheap sound card clipping.

Re:This is the Sound of

[mcgrew]

Damn, the anonymous cow is calling the po po on us! And hissing! See, the anonymous informers ARE snakes!

Re:This is the Sound of

[diegocgteleline.es]

I should...why? Pulseaudio works great here - no problems at all, no high CPU usage, nothing. It's funny that people will happily waste hours of their time getting rid of alsa while they critize pulseaudio for wasting their time with its problems...

It's clear to anyone that has looked into this that most people are very happy with Pulseaudio. All the important distros ship it, and the users that have problems are clearly a _minority_, which is only getting smaller and smaller with each new version of Pulseaudio, Alsa and the kernel. And the geeks that fear changes and love to bitch about are running out of excuses. Linux would have far more problems going back to OSS4 (hey, why I can't set per-app volume, why audio over bluetooth doesn't works as I want?).

Each time Linux redesigns some subsystem there are problems, and we see the same people bitching about how we should use $ALTERNATIVE instead and how Linux is not ready for the desktop. But with the time the problems dissapear and the linux desktop gets more and more solid.

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

[mcgrew]

Turning the volume louder than the total of 0db demolishes your speakers

Interesting, but incorrect. There are only two ways to blow your speakers: running pure DC through them can burn the coils out, and pushing more wattage through them than they are rated for can/will damage or destroy them. This is why amplifiers used to publish both peak and RMS wattages -- your speakers need to be rated at better than the amplifier's peak power, but to compare two amplifires' peak wattage is meaningless.

If indeed it allows DC to the speakers, then this is horrible engineering on everyone's part, even speaker manufacturers; all it tales to keep DC out of your speakers is capacitors in series with them.

Re:This is the Sound of

[Runaway1956]

"I should...why? Pulseaudio works great here - no problems at all, no high CPU usage, nothing."

No one suggests that you should tamper with what works. If you're happy with Pulse, fine.

"It's clear to anyone that has looked into this that most people are very happy with Pulseaudio."

No, most people settle for Pulse, because they believe it to be the best thing available. Since "most people" don't have any idea what Linux is, let alone Pulse, then "most people" can't be very happy with Pulse. But, to be fair, I should assume you mean "most people in the Linux community". Again, I have to say "No." If most people WERE happy with Pulse, there wouldn't be a zillion posts on the various support sites asking for help to get sound figured out.

"Each time Linux redesigns some subsystem there are problems, and we see the same people bitching about how we should use $ALTERNATIVE instead and how Linux is not ready for the desktop."

Switching sound systems doesn't require a redesign of Linux at all. I'm using the very same kernel with OSS4 that I used with Alsa/Pulse.

And, finally, Linux IS ready for the desktop. It's PEOPLE who are not ready for the desktop. Everyone who says that Linux isn't ready for the desktop should get a clue - millions of people with an IQ over 90 are already using Linux on the desktop. Those other millions with IQ's of less than 90 will never be ready for the desktop - so Microsoft is there to hold their hands, and make them feel good.

Re:This is the Sound of

[segedunum]

I should...why? Pulseaudio works great here - no problems at all, no high CPU usage, nothing.

I'm pleased for you. You've been lucky. That doesn't mean that others don't have problems though and no, I'm afraid they're not a minority when you look at the forums of many distributions and the bug reports. I suspect many people just give up to be honest.

It's clear to anyone that has looked into this that most people are very happy with Pulseaudio.

If they were then we wouldn't get articles like this and Lennart wouldn't be as defensive as he is.

Linux would have far more problems going back to OSS4 (hey, why I can't set per-app volume, why audio over bluetooth doesn't works as I want?).

They can and do, and at least it wouldn't break existing sound use cases for many users and existing applications and break the one sound card with speakers plugged in standard set up in many cases. We already have OSS -> ALSA and ALSA -> OSS interfaces that have been around for some time. PulseAudio reimplementing ALSA to look like ALSA is just plain silly. There's no point in solving some problems if you break a ton of others that have been solved previously.

All the important distros ship it, and the users that have problems are clearly a _minority_, which is only getting smaller and smaller with each new version of Pulseaudio, Alsa and the kernel. And the geeks that fear changes and love to bitch about are running out of excuses.

Dream on. Sound servers of the type that we have found in the Linux desktop world over the years have been strewn with cow pats from the devil's own satanic herd and should have largely been consigned to the trash years ago. We've had arts and esound largely to cover up for ALSA, no one has been able to agree on any one sound server, there are always a ton of issues and it always takes years to solve those issues. Talking about each new version of the kernel and PulseAudio to fix issues now after all these years when sound and even ALSA for many people have started to work is laughable. History, and the Linux desktop world's inability to learn from the past, is against PulseAudio but Lennart seems determined to bludgeon it in.

Re:This is the Sound of

[V!NCENT]

That's all very nice until another sound appears, like one in an error mesage for example? And PulseAudio is the only sound server that let's you manipulate sound on a per application basis. Oops?

Recording at -20db is abosuletly 100% FAIL and if the recording is bad then you should adjust the recording instead with mp3gain (http://mp3gain.sourceforge.net/) under wine or a Linux equivalent.

Re:This is the Sound of

[V!NCENT]

Yes, you have 'em. That's in speakers that have mid-, high-, and low speakers. BUT speakers that do NOT have this are not able to output all sound anymore. But what should adjust/limit output is the sound card in your computer in the first place. It is a waste of money to add that.

Re:This is the Sound of

[diegocgteleline.es]

I'm pleased for you. You've been lucky.

No, I have not been "lucky". I had problems with Pulseaudio in the past. I had to unistall pulseaudio. But the problems are fixed now. Just like your problems will be fixed, if they haven't already been fixed upstream. Hey it looks like you guys are overreacting here.

If they were then we wouldn't get articles like this and Lennart wouldn't be as defensive as he is.

Considering the high number of geeks attacking Pulseaudio with stupid reasons, I understand him.

PulseAudio reimplementing ALSA to look like ALSA is just plain silly.

Indeed. Long term maybe we can merge the libalsa functionality in pulseaudio and get rid of it. It would be far more clean. But that doesn't makes pulseaudio unnecesary.

We've had arts and esound largely to cover up for ALSA

Wrong, arts and esound were born largely to fix OSS....

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

[V!NCENT]

I am sure that if you feed it with a signal it can't handle it will not blow up. Try +100db on your laptop speakers but don't come crying to me that they went up in smoke. You can achieve a higher tone safely, but then you need to reduce the bass. This is what you get when you listen to pop music. Or you can increase the bass but you need to remove the loudness. You need to have an avarage of 0db as a signal. It's the balance of mid high and low and not the volume.

I can explain you why this is in RL and on paper, but it's a bit hard to explain in text :')

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

[Anonymous Coward]

fuck's just a word, get over it

Re:This is the Sound of

[u38cg]

The problem here is not with the audio system. Garbage in, garbage out. It is the job of the application to provide a suitable stream for playback, and building tools into the controls for dealing with something that is broken in the first place is a bad idea. And if you do have recordings that are too quiet, there are plenty of tools out there than will kick the gain up for you.

Re:This is the Sound of

[hannson]

Does it bother you that you agreed with him until he used dirty words?

An ad hominem argument has the basic form:

• Person 1 makes claim X
• There is something objectionable about Person 1
• Therefore claim X is false

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

[Jawn98685]

"Lighten up, Francis".

Re:This is the Sound of

[Jawn98685]

Yes, but it is NOT the job of the audio system to unilaterally decide to limit or prevent clipping, unless I fucking tell it to. My dumb ol' SET tube amp grasps that concept easily, playing at the volume I tell it to. Why can't my Linux sound system do the same.

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

[hcpxvi]

but after a week or 2 or so you will need to buy ned ones. ;)
I think that you have to live in Scotland[1] to really LoL at that one.

Hugh
[1] Where ned has a similar meaning to chav i.e. "person of great enough cluelessnes to enjoy deafening themselves with tuneless music turned up very loud"

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

[Anonymous Coward]

Buy speakers that have a higher power rating than the equipment you have plugged in. Then even on max settings you don't have to worry about your speakers...

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

[illumin8]

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.

A more rational solution would be to allow the user to check a box in the mixer that says "Normalize volume levels". What this does in software is apply a digital compression algorithm to the master output, similar to the compression you have on an FM radio station where everything is about the same volume (horrifyingly loud).

While this solves the user's problem of "it's not loud enough, make it louder" without them having to think about it, audiophiles simply have the option of unchecking the box and letting their ears try to hear the pristine, uncompressed -20db signal.

Modern CPUs are powerful enough to do this with only a small CPU load at very low latency. I'm not sure why they don't have this feature in modern OS environments like Linux, Windows, and Mac OS X already.

Re:This is the Sound of

[ichigo 2.0]

And you seemed credible until you dismissed his argument due to presentation.

Re:This is the Sound of

[Achromatic1978]

#!/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

And to think, they say Linux isn't ready for Grandma to use, yet!

Re:This is the Sound of

[adolf]

Community was a pioneer in the use of fancy light bulbs in series with loudspeaker elements as a simple, dynamic limiter.

The light bulb conducts very well while it is cold, influencing the sound very little. As current increases, the light bulb's filament heats up, and becomes more resistive. Thus, power is reduced. The effect is very dynamic, and able to be tuned to the loudspeaker drivers in question by designing a light bulb with application-specific characteristics. It's probably fairly expensive to design and build such a system and have it work properly.

It's not Community-specific: There's a few other manufacturers who use a similar method. The thing that they all have in common is that they are intended for pro audio use.

Another somewhat common method of limiting audio within a loudspeaker is to use a polyswitch, sometimes with a resistor in parallel with it (in order to turn things down by a predetermined level, instead of just switching it off). This method is slower, and more limited in application, but cheaper and easier to design for.

A much more common way to limit current to loudspeakers is the use of a simple fuse.

None of these things, however, are substitutes for using one's own ears to determine when things are too loud, and adjust levels accordingly.

Re:This is the Sound of

[shutdown -p now]

It's clear to anyone that has looked into this that most people are very happy with Pulseaudio. All the important distros ship it, and the users that have problems are clearly a _minority_, which is only getting smaller and smaller with each new version of Pulseaudio, Alsa and the kernel.

It was clearly a minority of users who had actual problems with Vista. Guess what, it was still a flop. A large enough minority having problems is also a big deal - and for PulseAudio, it's pretty damn large.

In fact, this from TFA:

he believes the majority of issues are being triggered by misbehaving drivers or applications

Sounds precisely like early Vista apologetics. What do I care if it's a driver problem when it bluescreens every 2 hours on me? Similarly, what do I care if it's a driver problem when my sound is messed up? Especially when both ALSA and OSS - which provide the drivers - work just fine on their own...

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

[Carewolf]

Because good speakers are two wires and a magnet. They are not electronic devices, they are electric. To make the cut-off the amplifier would need to know how much the speaker can output, but since anywhere near the breaking point is dead obvious to a listener it is usually redundant.

Re:This is the Sound of

[Random Destruction]

clipping.

Which destroys tweeters

Re:This is the Sound of

[Eunuchswear]

ITYM "fuck's just a fucking word, for fucks sake get fucking over it you fucking fuck".

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

[Anonymous Coward]

Wha?? How do you know that? It doesn't say in the article that Lady Gaga uses Linux

Re:This is the Sound of

[plague3106]

And, finally, Linux IS ready for the desktop. It's PEOPLE who are not ready for the desktop. Everyone who says that Linux isn't ready for the desktop should get a clue - millions of people with an IQ over 90 are already using Linux on the desktop. Those other millions with IQ's of less than 90 will never be ready for the desktop - so Microsoft is there to hold their hands, and make them feel good.

Heh... ya, ok. You keep telling yourself that.

Re:This is the Sound of

[horza]

The parent and grandparent posts should be framed and put on the wall of every Open Source programmer. Though diametrically opposed, they are both right. This bridge between our nice clean code, and interfacing with the reality of what is out there already, is one of the hardest compromises.

Phillip.

Re:This is the Sound of

[oldhack]

Yep, hard clipping concentrates large amount of energy onto the high frequency range, hence the tweeter protection. Fourier transform of clipping wave shows this very clearly. Signal processing 101. :-)

Re:This is the Sound of

[SiChemist]

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.

It's funny you picked that example. I don't know of any desktop system that will let you do that unless you are root, which requires a password.

Re:This is the Sound of

[raddan]

Why can't you stick an analog filter in there? Simply remove the undesirable frequencies.

Re:This is the Sound of

[Anonymous Coward]

They can and do, and at least it wouldn't break existing sound use cases for many users and existing applications and break the one sound card with speakers plugged in standard set up in many cases. We already have OSS -> ALSA and ALSA -> OSS interfaces that have been around for some time. PulseAudio reimplementing ALSA to look like ALSA is just plain silly. There's no point in solving some problems if you break a ton of others that have been solved previously.

You don't even know exactly what ALSA is. PulseAudio doesn't reimplement ALSA as kernel driver and kernel interfaces, it reimplements a low-level part of alsa library, which is a default way to access kernel alsa interfaces, and wraps it to PulseAudio API. At the same time it grabs ALSA controlled hardware and in exclusive manner (unless you have a hw mixing card). What's achieved this way is software mixing. Previously dmix was doing a very similar thing. Really, what PA does is not much different from OSSv4 except the latter has mixing in kernel so it is able to better emulate legacy interfaces, like OSSv3 and parts of libAlsa API that Lennart described as hard to virtualize and recommended not to use. However on top of userspace sound mixer it's easier to implement many fancy features that some people find usable, and are missing from any other Linux/Unix audio stack (including per-app volume, stream migration, Bluetooth audio support, network audio transfer etc.).

Some time ago sound servers sucked (except maybe dmix) because kernel part wasn't ready for it nor were they well designed. However Pulse Audio uses relatively new kernel features to avoid dropping and be as gentle as possible wrt. power consumption. At the same time it is able to adjust latency dynamically and provide very low latency if a client app requires it. These features are what makes PA a killer sound server, one that actually solves the old "Linux audio sucks" problem.

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]

"PulseAudio reimplementing ALSA to look like ALSA is just plain silly"

What the _hell_ are you talking about?

"Talking about each new version of the kernel and PulseAudio to fix issues now after all these years when sound and even ALSA for many people have started to work is laughable. History, and the Linux desktop world's inability to learn from the past, is against PulseAudio but Lennart seems determined to bludgeon it in."

I take it you're working hard on contributing all the things that PulseAudio is doing to ALSA, then?

That's the point that annoys me the post about this whole discussion - comment thread trolls who will bang on and on about how PA is a terrible idea and everything should be done in ALSA are ten a penny, yet people willing to contribute actual code to ALSA are rarer than unicorn shit. ALSA was effectively dormant for a decade - with barely enough contributors to write basic drivers for new devices, never mind implementing important new features - and when someone shows up with an actual plan to address the situation, all you can do is whine about how he's doing it all wrong. Then quit whining and do it 'right', and if your solution's a good one, it will be adopted. Development isn't a democracy. Whining about how things should be done differently is _not helping_.

Re:This is the Sound of

[OrangeTide]

Pulse blameshifts all it's problems to apps and drivers.

Indeed. Usually if an application is not working in pulse I can get it to work fine in OSS or ALSA mode.

But the biggest problem with Pulse is the devs.

This problem will solve itself. Some bored programmer will get sick of their shit and redesign the architecture once again. The process will repeat until equilibrium is reached where the right kind of team is driving it.

Re:This is the Sound of

[segedunum]

No, I have not been "lucky". I had problems with Pulseaudio in the past. I had to unistall pulseaudio. But the problems are fixed now.

No. The problems are generally with the sorts of things that PulseAudio wants to do which shows up problems in ALSA. Either the low-level component in ALSA needs to be fixed universally, we start using OSS as a better solution with better hardware support or we stop trying to bludgeon yet another sound server with an apparently compatible ALSA interface into the middle of an existing problem that we haven't necessarily seen, but has made worse.

You have been lucky with your hardware and your set up.

Indeed. Long term maybe we can merge the libalsa functionality in pulseaudio and get rid of it. It would be far more clean. But that doesn't makes pulseaudio unnecesary.

libsydney is still vapourware as far as I'm aware, and the ALSA interfaces are still going to be the most well used interface because no one is going to rewrite for yet another sound interface whose furture is uncertain. It would have been a better idea to use ALSA or OSS, solve the problems there and then build off them.

Wrong, arts and esound were born largely to fix OSS....

Wrong. They were needed more than ever for ALSA and we then got people complaining that ALSA was worse to program for than OSS so we needed yet another wrapper so we could cover our ears. I'm afraid you're not proving anything because whereas OSS 3 (not OSS 4) was not ideal at all, ALSA, arts or esound did not make the problems any easier or solve existing problems - quite the opposite in fact. The brain damage continued.

Re:This is the Sound of

[AdamWill]

"2. Pulse blameshifts all it's problems to apps and drivers. Ok, apps (open source ones anyway) will eventually get fixed. Drivers won't."

Saying the problem is in the kernel and it should be fixed there is not blame shifting, it is correctly identifying the problem.

A rather large hole is blown in your theory that drivers won't be fixed by the fact that they have been, are being, and will be fixed. Red Hat pays Jaroslav Kysela, and Novell pays Takashi Iwai, to do exactly this. Jaroslav, working together with Lennart, has fixed rather a lot of ALSA driver bugs that were exposed by PA already. They continue to work on fixing more.

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.

Re:This is the Sound of

[osiris247]

Overly simple: Power does not blow speakers. Distortion does. Your point is moot.

Re:This is the Sound of

[Korin43]

Exactly what problems do people have with Pulse anyway? The ONLY problems I ever have with sound on Linux are related to ALSA drivers not being updated yet (and that's Ubuntu's fault for its insane "Older is always stabler" policy).

Re:This is the Sound of

[Runaway1956]

For me, sound was choppy, scratchy, and sometimes I had to wait for buffers.

As for newer drivers - you are aware, I presume, that Ubuntu is a derivative of Debian. You can enable the Debian repositories for Lenny, Sarge, or whatever you like to get the newest drivers. Or, if you don't wish to enable a Debian repository, you can just download the driver from the repository, and install it. Ubuntu won't "support" a test driver, but it's "almost" certain to work. Do you care if Canonical supports it or not?

Re:This is the Sound of

[Anonymous Coward]

Have they fixed that little issue where you can't suspend without typing soundoff and soundon on a command line? (Or whatever it was...) Oh, and doing that kills all the apps that are using sound.

If I can't suspend without typing crap on the command line.... Then there is indeed a BIG problem.

-T

p.s. Really, why can't we just make all sound mix easily?

Re:This is the Sound of

[dubbreak]

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.

I have to disagree with that. While clipping can generate high order harmonics those will generally only hurt tweeters. When mids and woofers (sub woofers etc) get a clipped signal it's the extra power that sends them beyond mechanical or thermal limits that kills them.

Re:This is the Sound of

[Ant P.]

99% of media players have an auto volume normalisation option, another option to pick the dB level to normalise to, another option to choose between per-track or per-album metadata... why don't you use those instead of complaining that the kernel doesn't have yet-another-driver-module to do it (which by the way, it does already)?

Re:This is the Sound of

[BikeHelmet]

I remember reading about the audio quality of OSSv4. Apparently it's wonders better than Alsa.

I believe it. Alsa has noticeable hissing when playing movies. I've temporarily switched to PulseAudio, which seems to have cured it, but it's still not as good as in Windows.

I might try converting to OSSv4. I just wish the process was easier. :P

Re:This is the Sound of

[Khyber]

And how many amp/speaker combos did Hendrix blow out? Korn? They've both used over-powered speakers with under-powered amps. I'm doing it right now, I haven't had an issue for well over 6 years. It's a tiny 9v pocket amp and I run it directly into a 30w cabinet. No problems.

Re:This is the Sound of

[diegocgteleline.es]

The problems are generally with the sorts of things that PulseAudio wants to do which shows up problems in ALSA.

Well, ALSA can be fixed. Pulseaudio works closely with the alsa devs to make them aware of their problems. They seem to have fixed the problems here.

Why people just can't accept that Pulseaudio can work and does work for most people? I mean, distros wouldn't have been able to push it if didn't worked for most of people. Pulseaudio, Alsa, etc, seems to work exactly as expected. Can't you guys get over it and admit that it's not because we are not "lucky" but because the whole thing does work?

Re:This is the Sound of

[Godji]

Now if only OSS4 would support the Xonar D2X, I'd switch first thing in the morning.

Re:This is the Sound of

[Anonymous Coward]

Well yeah, Hendrix probably blew out a lot of amps - though notably, tube amps are significantly less prone to destroying speakers.

Most modern big-name hard rock bands have insanely massive amplifiers, and get all their distortion from pedals or dedicated units.

Re:This is the Sound of

[Anonymous Coward]

I wholly disagree. Those who feel profanity brings their point across more concisely should be more creative. It's harder, but more funner.

Re:This is the Sound of

[diegocgteleline.es]

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.

The current linux audio system was far from perfect. ALSA also was a minor improvement back when OSS + esd were the perfect world.

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.

The alsa drivers have lots of quirks to make sure it works for a given model of a given brand, just take a look at the sound/pci/hda git log output. There's nothing windows does here that linux can't do...

Re:This is the Sound of

[Knuckles]

Look into what analog filters do to the signal. There's a reason speaker design was a black art until the advent of computer simulation.

Re:This is the Sound of

[adolf]

Why?

Maybe because that only covers about 50% of the stuff that I use my sound card for. FFS, all of my MP3s are already set with mp3gain. But there's a world of things on Teh Intarwebs outside of MP3s, and I spend a lot of time listening to them. Youtube, various talk programs, political commentary... Lots of stuff which never actually touches my hard drive, which may or may not be properly produced, but that I still want to hear anyway. Some of it is recorded way too loud, while some of it is way too soft. Why have a tool as general as a VOLUME SLIDER which is able to correct only the former of those two problems?

And, besides: "Auto volume normalization," as implemented in practice, is simply a form of compression. I don't want the computer to ramp the volume up and down for me with some fancy algorithm -- I just want to be able to turn it up myself when the need arises.

Is there noone on Slashdot who understands that the world is imperfect, and that we exist within it anyway? And that there are some problems which do have very simple solutions, but yet cannot be programmatically corrected?

Alas, Slashdot. You make me sick.

Re:This is the Sound of

[Knuckles]

The discussion is not about guitar or bass speakers, but tweeters.

Re:This is the Sound of

[jeffstar]

most speakers are passive. they get the analog audio signal from an amplifier, run it through a coil attached to the driver in the presence of a static magnetic field and the driver moves creating sound waves.

there is no AC power source, no microchips, no hardware because these are passive speakers and why add more shit to raise the price? I was going to say cheap but you can spend a boatload on passive speakers.

if you overdrive something you damage it. try flooring your car in neutral and see how long it lasts.

Active speakers require power source and have an amplifier or something, hardware as you say, in them. never had any so maybe somebody else can expand on that.

Re:This is the Sound of

[adolf]

It's funny you picked that example. I don't know of any desktop system that will let you do that unless you are root, which requires a password.

Hrm.

I like that train of thought. Let's expand it.

If there were a way I could add gain to an audio stream using PulseAudio, at least as root, then I'd probably be happy. But I still can't, so it's still broken.

(I'm resisting the temptation to expound on the myriad of ways that a user can trash his own files without prompting, as that would be too much of a strawman for my liking.)

Re:This is the Sound of

[mrmeval]

Dammit you should post under your 'real' nym so I could send you a gift card number with enough on it for a couple of spendy large pizzas! Brat.

Re:This is the Sound of

[mrmeval]

It will only let you control an application WHILE IT IS PLAYING. Try setting the volume of some stupid ping that's one second long +50db in that second.

Re:This is the Sound of

[argosreality]

Actually, Windows does support this both under Vista and Win7. On a per device basis. I dont use it, and its hidden under the audio device properties but its there.

Re:This is the Sound of

[segedunum]

Well, ALSA can be fixed. Pulseaudio works closely with the alsa devs to make them aware of their problems.

Not the same thing.

Why people just can't accept that Pulseaudio can work and does work for most people?

Because it doesn't. Saying that enough times won't make it true. Most of the supposed ALSA issues will probably never be fixed because they have come about as a result of PulseAudio pretending to be ALSA and trying to pretend to be ALSA compatible interfaces.

I mean, distros wouldn't have been able to push it if didn't worked for most of people.

Poor argument. Distros have long proved that they will package up anything with little thought to how the system functions as a whole.

Can't you guys get over it and admit that it's not because we are not "lucky" but because the whole thing does work?

If it was working then no one would be complaining. People quite clearly are complaining.

Re:This is the Sound of

[sr180]

Its not the unusual frequencies at all - and by its nature - clipping doesnt add unusual frequencies, it turns the waveform into a flat DC voltage for a period of time. Theres no frequency.

Re:This is the Sound of

[Anonymous Coward]

You claim that tubes "really are better", but is it really? The flip side of softer barriers vs. brick-wall clipping is higher distortion for slightly non-clipped sounds. If you know when you're about to clip, there's no need for the "cushion" you get with tubes; you can simply avoid it entirely, and enjoy the better linearity of your semiconductor amps...

Re:This is the Sound of

[TerranFury]

Why should digital clipping be worse? I ask seriously.

The mental model I've got right now is that

digital_clip(x) = x if |x| < 1, sign(x) otherwise

(approximating the signal as real-valued and the output range of the amp as being [-1,1]) whereas

analog_clip(x) = smooth_sigmoid(x)

which results from saturation of the transistors used in the amp. Granted, the latter function is presumably smooth, which means fewer high frequency harmonics will be introduced, but the difference doesn't seem that huge...

Or by digital clipping do you mean "mod 2^N" clipping as whatever number representation used wraps around? Because I've never run across a sound driver that does this...

If the sigmoid is indeed a ton better than the piecewise-linear clipping function, then it could easily be implemented in software at the price of a tiny bit of undistorted dynamic range...

So what's the deal with "digital clipping?"

Re:This is the Sound of

[TerranFury]

Philosophically, time doesn't exist in the frequency domain. As for clipping, it turns sinusoids into square waves, the Fourier transform of which has evenly-spaced harmonics going out to infinity (and decaying as 1/f) as described here.

Re:This is the Sound of

[TerranFury]

In principle, I suppose one could use an IR sensor (like that used in some electronic medical thermometers) to estimate the temperature of the voice coil without affecting its dynamics.

Re:This is the Sound of

[glittalogik]

I've been trying (every now and then, but for longer than I care to remember) to achieve the same thing except with analog speakers and a bluetooth headset. No luck yet...

Re:This is the Sound of

[sr180]

Yes, if we were digitising this - then those harmonics would be causing us major havoc without a filter. But because we are sending this to a speaker, these harmonics are irrelevant - its the DC voltage doing the damage.

Re:This is the Sound of

[AdamWill]

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.

I've been trying (every now and then, but for longer than I care to remember) to achieve the same thing except with analog speakers and a bluetooth headset. No luck yet...

First poster: in case you're not sure (I can't quite tell), dmix mixes multiple *streams* - different apps playing audio, essentially - to a single output device. It has nothing to do with handling multiple output devices.

dmix works only with ALSA-native output, it doesn't mix OSS-type audio. PA can mix ALSA-native, PA-native or esd-native streams, but not OSS-native. If any of the apps you're trying to use outputs OSS-style (direct to /dev/dsp as a file), neither dmix nor PA will be able to mix it by default. If it will run through padsp (Pulse's wrapper for OSS-style audio) or ALSA's similar wrapper (I forget what that's called), mixing the output may work. Otherwise, both ALSA/dmix and PA should be able to handle your mixing needs.

Choosing an output device you can do with both ALSA and PA, but it's a heck of a lot simpler with PA. With ALSA you need to identify which driver each of your devices uses, then use the index= parameter for those modules in /etc/modprobe.conf (or /etc/modprobe.d/somefile.conf , depending on your distro's conventions). Something like:

options snd-usb-audio index=0 options snd-hda-intel index=1

would ensure that the USB audio device (or _one_ of multiple USB audio devices, if you have more than one; you wouldn't get to pick which) became the default output device, and an onboard Intel HDA adapter became the secondary output device, at each boot. If you don't specify index parameters, whichever module happens to load first gets to be the default device (yes, this is the wonderful ALSA design that's getting so much praise in this thread).

With PA, you use a Pulse-compliant mixer (gnome-volume-control, pavucontrol, whatever) to pick a default output device graphically. Nice and simple. I can't tell you what problem you're having with PA without more detail than 'fell flat on its face'.

Second poster: Complete Bluetooth audio support only landed in PulseAudio in June or so, IIRC. After the last round of distro releases. Fedora 12, Mandriva 2010 and Ubuntu 9.10 include the easy Bluetooth audio support, earlier distributions don't.

Re:This is the Sound of

[glittalogik]

Thanks for that! I thoroughly broke everything sound related mucking around with stuff I shouldn't have in 8.10, so I'll be having another crack with a clean install of 9.10 when the release version comes out.

Re:This is the Sound of

[jwdb]

You're fairly close, but the cause is not the supply impedance. Semiconductors will indeed run linearly rail to rail (in a linearized circuit, as most amps are) but tubes are used with much less linearization than silicon and thus a tube amp will start to distort at a significant distance from rail voltage. This means that tube clipping is more rounded compared to the abrupt clipping of transistors - running out of steam, as you say. Rounding off the clipping leads to even order harmonics instead of odd order, and these sound more pleasant because the human voice contains predominantly even harmonics.

Check out a plot of tube current versus grid voltage (for constant plate/supply voltage) if you want more details. You'll see that on the low end (negative grid voltage) the current rolls off as it approaches zero: soft rather than abrupt clipping. There is no roll-off on the high end (zero grid voltage) but as soon as the grid goes positive it begins to conduct, a change in input impedance dependent on input voltage which also leads to distortion and rounding off (if your source has a nonzero output impedance and/or there is a nonzero grid resistor, of course).

Re:This is the Sound of

[Jawn98685]

You are quite right, of course, about the behavior of a valve amplifier as it reaches it's limits, but that's not the point I was making. I was talking about a user interface (a knob) that obeys my commands, regardless of the sonic effects that it may judge I ought not to suffer. Linux sound systems are far, far away from that simple elegance, reliability, and tractability. Don't get me wrong, much of my audio collection lives on and is delivered by an Ubuntu box, but between Amarok and the cable going to my amp, things are mess.
Why?

Re:This is the Sound of

[Khyber]

Never played a guitar, I can tell. Come back when you learn about false and pinch harmonics, and how you can destroy tweeters with them.

Re:This is the Sound of

[dpilot]

Broca's Brain?

Sometimes I think it's because fixes accrete in layers.
Sometimes I think it would be better to just rip some garbage out, maybe even to compatibly reimplement. For instance, consolidate 2 or 3 separate layers into 1. Maybe even wait for the deadline scheduler to go mainline, then fold both JACK and Pulseaudio functions and APIs into ALSA. With a little luck massive amounts of code could be thrown out, function would be preserved, and all would get better.

Re:This is the Sound of

[ksheff]

except when it breaks use cases that just worked for years. The following 'feature' was quite annoying. I'll have to try this out at home. I sort of got it working, but it wasn't what was outlined here (I have NFI how, actually) - too bad it took 3 months to get a real answer. https://bugzilla.redhat.com/show_bug.cgi?id=505676

Re:This is the Sound of

[Knuckles]

Yes. Tweeters. That's what I said. Not 12" speakers in Marshall stacks et al., which is what I read when you asked, "how many amp/speaker combos did Hendrix blow out? Korn?".

Re:This is the Sound of

[ksheff]

For me, the sound seems to be 'sped up'. I can listen to a video or a music file on a different machine and it sounds fine. On the pulseaudio machine, it's about 1/4 of the way between 'normal' and 'Alvin and the Chimpmunks' mode. Prior to that, it would lag and hang up watching videos (youtube, vlc, etc).

Re:This is the Sound of

[AdamWill]

that was unfortunately just on the other side of the 'common enough use case to account for in gnome-volume-control' line. The idea of the new g-v-c is to present sufficiently commonly used functions in a simple and understandable interface (whereas the idea of ALSA mixer applications is to present every possible function in an interface which looks like it was designed by a crack-addled monkey :>). basically the way to configure this is to bypass gnome-volume-control. In F11 we provided gst-mixer (which was really the old gnome-volume-control) for this purpose, in F12 you'll have to use something else, like alsamixer . These apps still expose the full ALSA mixer interface, so you can set up things like this if you need to. To control the input channels you run something like 'alsamixer -c0 -Vcapture'.

Re:This is the Sound of

[AdamWill]

that sounds like a sampling rate bug (I think we've seen this in cases where the driver was providing bogus sampling rate information). have you filed a bug on it where I can ask for the appropriate information to investigate?

Re:This is the Sound of

[ksheff]

Not yet. What hw and environment information is normally requested for cases like this? I'm guessing this also needs to go to fedora's bug tracker so it can be determined whether or not something that the distro maintainer can handle or if it needs to get passed further up the food chain.

Re:This is the Sound of

[Korin43]

You do realize that Ubuntu is Debian in fast mode right? I'm sure I needed drivers from 2003, Debian would be happy to provide them, but that doesn't really help me in this case.

Instead I just installed Arch and followed the simple instructions on their Wiki for Alsa and PulseAudio (add ~4 lines to an alsa config file) and everything works fine.

Re:This is the Sound of

[Korin43]

I just looked it up to make sure I wasn't missing something, and Debian splits alsa up strangely so it's hard to say exactly which package is which, but Debian's ALSA packages have versions from 1.0.15 (released Oct 2007) to 1.0.17 (released June 2008), and ALSA current is entirely 1.0.21 except for ALSA-OSS which hasn't been updated since 1.0.17. So, Debian has no ALSA packages less than two versions off, and the majority are around 7 versions off. Sources: Debian Stable Package List and AlsaProject Homepage.

PS: Ubuntu, being released much more frequently, has managed to update to ALSA 1.0.18 (released Oct 2008).

Re:This is the Sound of

[Runaway1956]

Ahhh. I wasn't aware of that. It's possible that I could have fixed my problems with sound just by installing an up to date ALSA. I'll try that the next time I do an install.

Sometimes, google gives you more information than you can properly digest, lol

Re:This is the Sound of

[AdamWill]

it's worth noting that the most important ALSA bits - the drivers themselves - are in the kernel package. The packages with 'alsa' in their name are just user-space support stuff, and them being up to date is somewhat less important. The most important thing to know is which alsa-drivers version is in the current kernel of the distro you run, that's the vital bit.

it follows that if you want to try a newer ALSA, try finding a testing build of a later kernel for your distro, or just re-build the alsa-drivers bit, you don't need to bother rebuilding the rest, it's unlikely the fix for any driver bug is in any other bit of ALSA.

Re:This is the Sound of

[AdamWill]

https://fedoraproject.org/wiki/Bug_info_kernel_sound contains the instructions for filing good reports on sound problems. Note it links to a similar page for PulseAudio, with instructions to follow if the issue seems PA-related.

Re:This is the Sound of

[V!NCENT]

People that think like that need to be shot, seriously :(

Re:This is the Sound of

[shentino]

Isn't this called companding?

Re:This is the Sound of

[electrosoccertux]

I'm referring to, say, audio from a CD, vs audio from a video on youtube, which may be extra quiet because the guy didn't master correctly. VLC lets you boost to 200%, which can be invaluable if the source isn't very loud. Just doubling the amplitude...am I missing something?

Re:This is the Sound of

[Anonymous Coward]

Try asoundconf-gtk

It has worked like a charm for changing your sources. Unfortunately you cannot use it with Karmic as the Ubuntu folks removed an alsa util that asoundconf-gtk relies on. I forgot which one or I'd hand it to you. So, I loaded the Intrepid version of alsa-utils and it has worked until this week. If anyone knows of a good KDE distro without pulseaudio in it, I'd like to switch. Ric
 

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.

[DNS-and-BIND]

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?

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.

[UPi]

On a related note, haven't we recently seen the pattern of blaming drivers and applications, done by a certain megacorporation, as a way of explaining the failure of a recent operating system? Don't they have a patent or something on doing this?

Re:who's to blame.

[donaldm]

Actually if you don't like PulseAudio you can remove it and just use other audio packages like Alsa. I found PulseAudio was painful to use since it was like you had to fill up a bucket before the sound was acceptable, unfortunately I got pops and drop-outs which were annoying so I just removed it and stuck with Alsa which does have some latency issues but nothing like PulseAudio. Still if you use Fedora 11 like I do I can't really complain since these are the sort of things you expect when you are on a cutting edge release..

My main complaint at the moment is ZSNES and GENS which use SDL. The sound worked well in Fedora 10 but since Fedora 11 sound does not work for these applications even after removing PuseAudio. I don't have any issue with Xine or VLC providing I select Alsa or just remove PuseAudio. This is not a big problem for me but one day I would like to get this fixed. I am hoping this is going to be fixed in Fedora 12 although I won't hold my breath.

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.

[noundi]

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.

It could also be a hardware issue or a driver issue. This is not even up for discussion. This is how Linux and Windows work. Period.

Re:who's to blame.

[Anonymous Coward]

one of the major annoyances of ubuntu 9.04 was having to kill pulseaudio at each startup so that sounds would work. i'm glad i'm back to windows

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.

[noundi]

most of the time, however, the issue is there only with pulseaudio. my machine works like a charm without it and stutter with - the developer will have an hard time convincing me that the bug is not in his software, as alsa and arts had never had a problem previously.

Fair enough, and I won't argue against that. However the GP was making an incorrect assumption. This is what I objected to. It's misleading and should be modded down.

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.

[AvitarX]

When a computer can't suspend and resume with Linux, but it can from Windows, do to the hardware not doing as it claims to do, I suppose that is a Linux problem too?

I'm not saying Pulse is without problems, simply your premise that if Pulse does it only, it must be Pulse, not a driver or hardware.

Re:who's to blame.

[Anonymous Coward]

Especially since the tard can't even spell PAID.

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.

[V!NCENT]

It's not a bug; it's a feature. Ha.. ha.. h-... no I am not joking: having max volume music playing while you awnser the voip sucks, so apps should be able to turn of or lower the sound of other apps, but if the app crashes then yeah... that sucks.

Re:who's to blame.

[Tei]

A application sould not break the OS. That was MR. GENERAL FAULT windows 3.1 commander :-)

But PulseAudio is not application. Could be, I am speculating... that PA has to manage direct access to hardware that is poorly designed, so It could crash (maybe even the entire computer) because this poor hardware design? I don't know, I am just asking.

Re:who's to blame.

[QuoteMstr]

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.

Pulseaudio is not an application. It is a system component that happens to run in userspace. Why aren't you complaining that if you kill X, your desktop dies?

We're getting further and further away from the monolithic kernel model. It's something you'll just have to live with.

Re:who's to blame.

[Anonymous Coward]

Aaaaaaaaaaaaaahwwwwwww Q_Q.... cry cry cry... *sigh*

Re:who's to blame.

[betterunixthanunix]

ALSA was not behind Windows. Actually, my sound system was working fine until Pulseaudio came along. Now the only problem is the massive amount of CPU time Pulseaudio uses.

Re:who's to blame.

[TheSunborn]

If any application could kill X and thus prevent other apps from working that would be worth complaining about too, but I have newer seen that happend on my many years as a linux desktop user. Maybe I am just luckey :}

Re:who's to blame.

[PincushionMan]

Same here. We need to tag this article oss4rocks.

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.

[meow27]

thats funny, because alsa and OSS give me that problem

Re:who's to blame.

[Interoperable]

I think the current state of audio on Linux is to blame, and it's Pulse (well OK, everyone else as well) that's trying to fix it. Much of the trouble arises from not having a consistent standard to deal with across all Linux flavors. I agree that only having one choice would go against the grain of the Linux philosophy, but at the same time it may make it more likely for hardware developers and software developers alike to try to make compatible stuff.

Pulse is much better today than it was even a year ago and when it works, it works damn well. Give it some time to mature and as it acquires more market share we'll see much better compatibility.

I was completely converted to Pulse when I was able to stream music from any PC to any other PC in my house. It really is awesome to have the mpd server on my media center stream flawlessly over my network.

Re:who's to blame.

[u38cg]

Well, it depends. I certainly want something a lot more sophisticated than just a /dev/dsp that everything gets written to. When I'm playing a DVD, I do not want some stupid flash ad to start talking to me. I don't want a ding noise informing me that updates are ready. So a certain level of smart behavious would be good. Likewise, working networking features would be good: I'd like to be able to hook up my MP3 collection to the hi-fi via the laptop that sits in the living room, and so forth.

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.

[Xtravar]

AGREE. My system worked until PulseAudio RPMs got installed. I reverted to Alsa, but I'm scared about what some future distribution release is going to do to me. Who the fuck thought this was a good idea?

Re:who's to blame.

[visualight]

He's a child. A talented programmer, but still a child. I'm sure when he matures he'll regret making that comment, if he doesn't already.

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.

[drinkypoo]

I don't disagree with that, but the reality is that it's possible to execute a DoS against the Linux kernel, even accidentally, and degrade system performance... So why not pulseaudio? Also, if you follow PerfectSetup and stay away from the most retarded applications, you will likely never have one problem with pulse, while it gracefully allows you to pipe your audio around the house at will. Some people don't care; let them eat ALSA... suckers.

Re:who's to blame.

[Anonymous Coward]

There's a closed ticket in Pulseaudio's Trac on which he said portability outside of Linux doesn't matters. This is even when he lists Pulseaudio ports for other SOs as a feature in the main page... "PulseAudio is a sound server for POSIX and Win32 systems"... ridiculous.

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.

[Anonymous Coward]

lol

prick. not every computer user is a programmer and not every progammer wants or is able to write every piece of code.

Re:who's to blame.

[thejynxed]

Isn't there a way to maintain the silly dependency files but not invoke the entire "broken" interface to that subsystem?

I know you can do this with at least IE and Windows Media Player on Windows, where you can remove the entire front-ends and other assorted dross, and still retain specific files required by other Windows versions of programs/native apps like WinAMP, Firefox, the MS DRM subsystem, Windows Help, Windows Explorer, etc to function properly. I know nLite allows this, as do several other 3rd-party apps for Windows, as well as Microsoft providing versions of Windows Media Player components that you can install instead of the entire player application, so that programs like WinAMP, etc can access DirectX Sound, streaming audio in MS-specific formats, DRM licensing, etc (Kind of like a developers version, where devs could use those specific data files, and then program their own front-end to replace the one provided by MS if they so chose).

It seems ridiculous to me that this isn't more easily done and that mandatory userland programs and system settings are being specifically tied into certain subsystems/3rd-party programs by default without providing acceptable functional alternatives. This is especially true for an operating system that is supposed to represent "Free" and "Open", but apparently is showing behavior that compares more to the SCO or Apple way in this situation.

Re:who's to blame.

[sarhjinian]

The comment about video/compositing is interesting, because if there's anything worse than Linux audio, it's Linux video. At least with Pulse you can see the light at the end of the tunnel; I have no idea how the Driver/GEM/Mesa/DRM/DRI/GLX/XAA/EXA/UXA/KMS/Xv/WTF/BBQ clusterf_ck will ever get sorted out, not when everyone seems to be working on parallel, incompatible products. And yes, I know that if I get some experimental driver from X.org's git server and/or make sure I only use Intel/nVidia/ATi and/or precisely tweak xorg.conf. Eventually I did that, but there's no way that video should be as inconsistent as it is for this long.

Meanwhile, I can run a hacked-up version of OS X on the same hardware and somehow video just works. No tearing, no stuttering, no worries.

Pulse, by comparison, isn't so bad. I managed to get it working such that I could play to my Airport Express, USB headphones, desktop speakers and/or a combination of the above on a per-app basis, all without involving git or dealing with drivers. If it has a problem, it's that the tools to manage it aren't well-integrated into many distros (Ubuntu, I'm looking at you) and aren't terribly user-friendly, and that applications can bring it down. That's a serious problem: a driver killing the sound system is fine, in a way, but it shouldn't be possible for, say, Songbird or Flash to kill audio any more than it should be possible for them to kill your display server.

I can see the point of PulseAudio, and what it needs is a little polish and robustness. Video on Linux, though, is showing the worst symptoms of "too many cooks" and "herding cats". Worse is that we've come to accept this as the status quo.

Re:who's to blame.

[markov_chain]

It is not surprising. The ALSA API seems like a very complicated API to use, with lots of redundant functionality and various legacy interfaces. If I were writing a driver for it I would probably cut corners and get the bare minimum working.

I hear that OSS4 is much cleaner in this regard.

Re:who's to blame.

[sarhjinian]

"Why aren't you complaining that if you kill X, your desktop dies?"

Because that's not analogious to what Pulse is doing. A better analogy would be if Firefox's crashing killed your whole X session and left your video card in such a state that you couldn't bring X back up until you rebooted.

Sure, the flaw is in Firefox, but there's no way a fundamental subsystem like Pulse (or X) should be so incapable of handling errors gracefully.

Re:who's to blame.

[jhol13]

Maybe that is one of the reasons for: http://opensolaris.org/os/project/opensound/?

Re:who's to blame.

[eison]

Shouldn't the idea of "move these bits representing music from here to there" be a separate application from the idea of "turn these bits into sound coming out the computer's speakers"? Especially since in most cases the "move these bits" step won't be desired?

Re:who's to blame.

[thePowerOfGrayskull]

That was my first thought when I read this -- this argument sure sounds familiar, it's just that we're usually hearing about it as a way to justify video issues with Vista. That doesn't mean there's not a grain of truth to it (as is the case with Vista). Where I have an issue is not with the statement about drivers, but "drivers and applications" -- because it's not reasonable to expect that an application that is misbehaving will break sound for other applications that aren't.

Re:who's to blame.

[dbIII]

It's the late 90s gnome attitude all over again from when they wanted Enlightenment for a window manager but gave nothing back apart from breaking it on every platform apart from x86 linux. Then gnome started to grow up after they were rejected by a small but well run project. Or if you prefer it's like the RMS "linux? Never hurd of it" insult when linux was new.
It looks like a single platform abstraction of audio with so little flexibility that a major kernel change is likely to break it. What's the point of putting an extra layer in when it's so fragile?
Every half decent free software project is cross platform for a lot of good reasons.

Re:who's to blame.

[shutdown -p now]

Fixing drivers generally requires more specialized knowledge and skills than fixing a userspace application.

Re:who's to blame.

[shutdown -p now]

I particularly love this:

Regarding API stability: as with my other project Avahi I will not guarantee
any API stability. All I do is that I promise to try my best to keep the interfaces stable.

Oh, great. Unstable APIs in the kernel are at least understandable (even if arguable). But unstable APIs in userspace is a recipe for a disaster.

Re:who's to blame.

[MrCrassic]

Never mind the fact that USB audio devices are still hit or miss. I wish USB audio support would be a bit more extensive across the board.

It's a shame that I can't use my Creative USB audio card on practically any Linux distro or OS X b/c of the lack of driver support.

Re:who's to blame.

[AdamWill]

"most of the time, however, the issue is there only with pulseaudio. my machine works like a charm without it and stutter with - the developer will have an hard time convincing me that the bug is not in his software, as alsa and arts had never had a problem previously."

if only things were that simple. However, they aren't. Most stuttering issues observed with PA are indeed caused by kernel driver bugs. PA uses more of the ALSA API - the *public* ALSA API, which is exactly what other apps are allowed to use and which is supposed to work - than most previous applications have done. Hence PA exposes bugs in ALSA which have been present but unnoticed until someone came along and actually tried to _use_ the functions in question. This is the case with almost all of the stuttering issues. Most of them have been fixed by ALSA driver fixes in recent ALSA / kernel releases. See https://fedoraproject.org/wiki/Bug_info_PulseAudio#Playback_problems.2C_crackling_or_skipping for a workaround.

Re:who's to blame.

[BLKMGK]

Ding Ding! Right there with you on the .asoundrc issue! Thing is I think that this config file is for ALSA and not PA. I had to update ALSA on my system just to SUPPORT HDMO sound with my NVIDIA chipset. This has driven me NUTZ on FOUR different XBMC installs. thankfully some folks have put together files to work on many of the most popular pieces of hardware and posted them to the support forums for XBMC. This stuff IS slowly maturing but man it's painful sometimes!

Who knew sound could be some complicated to setup? I swear in Windows if you've got the right drivers it's EASY. Not so Linux and if it weren't for the folks out there helping I'd have been forced to give up too :-(

Re:who's to blame.

[Zerimar]

The problem with multimedia is the reason I went back to Windows Vista as well. HDMI video and sound out was effortless and flawless in Windows. With Linux, it was hours of mucking around to get it "kind of working".

Re:who's to blame.

[srwalter]

Bah!
As a computer user I do not have time to do that.

Okay, then pay someone else to. Even if that means paying Microsoft or Apple to deliver you a working sound system. You aren't entitled to anything for free.

Re:who's to blame.

[srwalter]

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.

Yeah, I guess grandma will just have to use SPDIF output instead of HDMI. I'm sure she'll be heart-broken.

Re:who's to blame.

[AdamWill]

"It's a shame that I can't use my Creative USB audio card on practically any Linux distro or OS X b/c of the lack of driver support."

Unfortunately, Creative decided the perfectly good USB audio standard which every other USB audio device under the frickin' sun uses is not good enough for them, and used an entirely different interface for their USB audio devices. Which they then didn't give anyone any specifications for, so no-one could write a driver.

I _think_ the recent spec release which is leading to a usable X-Fi ALSA driver covered the USB hardware too, so a working driver may be available soon / already in recent enough ALSA releases. But I haven't followed that particular wrinkle very closely.

Any USB audio device which actually uses the USB audio standard should work fine with the snd-usb-audio driver. I've used quite a lot of such devices, and haven't found one that doesn't work yet.

Re:who's to blame.

[segedunum]

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?

Because if the issue is really there then we need to be looking at solving it at that level and not bunging yet another in a long line of sound servers into the mix and making the problem even worse and then denying any responsibility.

Re:who's to blame.

[vivaelamor]

I am unsure where plain ALSA is failing that OSS4 isn't except in limited cases, perhaps where a device is further ahead in support? I hope you submitted details of your problems to the ALSA devs.

With regards to Pulseaudio, it uses the hardware in a different way to the OSS4 and ALSA APIs which is why you are unlikely to see a lot of the long term benefits of Pulseaudio ever crop up in OSS4 or plain ALSA. Because of the way Pulseaudio uses the sound hardware (a way that does make sense in the long term strategy of making audio perfect in all use cases with one system), issues crop up that didn't before such as drivers providing bad timing information, which you can see only matters if the audio system wants to be more efficient rather than settling for just working. There is a page summarising known bad drivers and what can be done about them.

My impression of most of the negative posts is that people are unhappy using a system that has not been thoroughly tested. That is a fine sentiment but I worry that it is leading to a conclusion that Pulseaudio offers nothing worth the hassle which I can assure you is far from the truth if people truly want a system that compares (or beats into submission) that found on Windows and OSX. OSS4 does not offer such a system and shows little intention of ever doing so and ALSA needs these hurdles overcome for Pulseaudio to do so.

Re:who's to blame.

[Runaway1956]

You mention timing issues. And, that was the root cause of my problems with virtual machines. All other little foibles with Pulse were acceptable to me, but those VM's simply could not make decent sound through Pulse. It took me some searching on the various virtual machine forums to understand that it was a timing issue. Once I understood that, it only took a few google searches to point me at OSS4. Those timing issues are non-issues for me now.

And, don't ask me to explain all the timing stuff. It's over my head. If you're interested, I found the most useful information on the Parallels VM forums, with some posts at Sun's VBox forum substantiating what I read at Parallels.

Re:who's to blame.

[AdamWill]

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?

Because if the issue is really there then we need to be looking at solving it at that level and not bunging yet another in a long line of sound servers into the mix and making the problem even worse and then denying any responsibility.

But...that's not at all what is happening. What is happening is exactly what you said. Where PA exposes kernel bugs, those bugs are being fixed. No-one ever said otherwise. All Lennart said was that sometimes the bugs are in ALSA, not PA. He then *specifically* said that does _not_ mean they should not be fixed, or that he's not interested in fixing them. Yet you choose to draw that conclusion anyway...

Re:who's to blame.

[jasonwc]

I thought I would describe my experience doing the same in XP, Windows Vista, and Windows 7:

Windows XP: Connect HDMI to external display. Turn on machine. Manually select external monitor in NVIDIA settings. Sound outputted to TV automatically.

Windows Vista: Connect HDMI to external display. Manually select external monitor in NVIDIA settings. Manually select HDMI output in Control Panel (easy to do).

Windows 7: Connect HDMI to external display. Windows automatically switches to external display and outputs sound to TV. Disconnect to automatically return to PC speakers/laptop monitor. (Used Intel Integrated Graphics)

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.

Re:who's to blame.

[John Betonschaar]

She will be if she wants to hook her new linux-powered media PC to her Sony Bravia TV, which has HDMI input but no SPDIF.

And before you bite: yes, I suggested analog because you won't hear any difference over the TV speakers anyway, but when that didn't work straight away either I took the plunge and scourged the interwebs to finally find out how to get the HDMI output working.

Re:who's to blame.

[dotancohen]

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.

F/OSS, stage 1:
Get involved, file some bugs!

F/OSS, stage 2:
Actually, file a patch.

F/OSS, stage 3:
If you don't like it then go write your own damn software.

Seen this week on the KDE-Usability list.

Re:who's to blame.

[dotancohen]

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.

Tell that to the KDE4 devs:
https://bugs.kde.org/show_bug.cgi?id=196379

In short, non-composting KDE4 is designed to look like garbage.

Re:who's to blame.

[Anonymous Coward]

Professionalism sucks. Abandon it now.

Re:who's to blame.

[segedunum]

But...that's not at all what is happening. What is happening is exactly what you said. Where PA exposes kernel bugs, those bugs are being fixed.

No, they're not being fixed because it's extremely difficult to fix something in ALSA as a result of a piece of software (PA) that is pretending to be ALSA. That's where most of the bugs are coming up, and it's something that can never be practically fixed. Reimplementing yet another sound server to look like ALSA for backwards compatibility was always going to be a stupid thing to do.

He then *specifically* said that does _not_ mean they should not be fixed, or that he's not interested in fixing them. Yet you choose to draw that conclusion anyway...

I draw that conclusion because that's the net end result - the blaming of anything else apart from PulseAudio.

Re:who's to blame.

[Daniel Phillips]

In short, non-composting KDE4 is designed to look like garbage.

I'm using KDE 4 without compositing right now and it looks fine.

Re:who's to blame.

[AdamWill]

"No, they're not being fixed because it's extremely difficult to fix something in ALSA as a result of a piece of software (PA) that is pretending to be ALSA."

Would you please stop drivelling? Also, please stop your one-man King Canute crusade against reality? The crackling / stuttering issues experienced by some people in Fedora 11 and equivalent distros were _all_ cases of kernel driver probelms being exposed by PulseAudio functionality. Dozens of bugs with hundreds of comments in each were filed, which together covered many different instances of this kind of bug. The vast majority of these were fixed, others continue to be fixed as ALSA development goes along.

Take a stroll through https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=crackl&classification=Fedora&product=Fedora&bug_status=CLOSED .

Re:who's to blame.

[rajafarian]

I spent about a week getting it working on my Debian Unstable system, especially learning about how it works. To me, it was totally worth it! I have my motherboard's on board audio and then I have a PCI HT Omega Claro Halo connected via optical to a home theatre receiver and to headphones. I can direct the sound of kaffeine, amarok, youtube, and mupen64 dynamically to any of them without dropping sound at all. For a big while every application "skipped" at the beginning but they don't anymore. It still doesn't detect/configure the digital connections on either the onboard or the Claro Halo but I learned enough that I can fix the problem. Why fix? Well, once or twice it stopped working altogether. Ha ha.

I love Pulse. Technically, it's awesome! My nephew brought his USB Audio card and Pulse detected it right away and I was able to also direct sound to it dynamically. But I also love to learn and I think many people don't have the time or skills to figure it all out right on their own. Oh well, Alsa, and OSS are still there. Pulse is not going away, nor should it. And then there's the issue of the kernel needing to be compiled with certain options, like low latency...

My only problem now is that it won't detect the digital connections and it has no easy way to bypass itself, i.e. from the GUI, for Dolby Digital or DTS. Considering all the issues I had in the past... shoot, just getting it to work, I think that they're going to fix any issues that non-technical people can't figure out and most everyone will forget this debate ever happened.

Re:who's to blame.

[Anonymous Coward]

What happened to me in ubuntu (Your mileage will probably vary) was that libsdl only supported PulseAudio. Try looking the description of the package/alternate sources...

Re:who's to blame.

[dbIII]

Gnome does a lot more than break gimp compiles with every release and is on a lot of platforms now - they grew up a long time ago. Even gconf is going somewhere towards being useful and sometimes usable.

Re:who's to blame.

[vanilla_face]

Thats OK then, they can keep on using their Pulse on top of ALSA. Please do not put it anywhere near OpenSolaris and our beautiful OSSV4 Audio!

Re:who's to blame.

[Anonymous Coward]

Well, to be fair, I have seen lots of people with sound issues in windows. With Vista/Windows 7 My soundblaster live 5.1 card is not supported and thus you need to use a third party driver which blue screened quite frequently. True its old hardware, but its much better than the newer integrated sound card that came with my 4 year old computer. In ubuntu I have never had a problem on the same computer.I did once attempt to get hdmi out working on my laptop but hdmi out was brand new for laptops at that time so I just plain didnt expect it to work. Haven't tried since but I've heard that it can be done.. But you have to remember that unless the manufacturers supply drivers for these things that its going to take a bit of time before they are well supported.
Your grandma isnt likely to be using hdmi output anyways. In fact, she should probably get back to sewing clothes for her grandchildren.

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

[Cyberax]

Yeah, sure.

How does floating point works for you in the kernel? And what about Bluetooth?

Well, thought so.

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

[Anonymous Coward]

As long as BS like this is accepted as 'normal', it will never be "the year of the linux desktop".

Re:Useless

[timmarhy]

uhuh, who gives a crap about bluetooth when the sound daemon itself keeps bombing out?

Re:Useless

[Anonymous Coward]

PA is great for thin client IF it works. We use ubuntu ltsp servers for our school and the audio only works on 8.04. From 8.10 onwards just playing 5-10 second of video is enough to loose the connection the audio server. And it wont't come back until you restart the thin client. What a mess. They introduced new bugs in PA, did not enough regression testing and released that POS to the public. I cannot upgrade to newer ubuntu versions without breaking audio and have to hunt through backport repos to get current version for important programs (OOO for instance). Thank you PA!

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

[Anonymous Coward]

How about using Spotify on my laptop and hearing the music from my media server.

But feel free to come up with stupid use cases, that's a lot easier ("This fork is useless for eating soup!").

Re:Useless

[Anonymous Coward]

So then windows isn't very ready for the desktop either.

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

[IBBoard]

openSUSE had a buggy Pulse Audio implementation when I first installed it (caused by buggy Soundblaster drivers, apparently, and something no so great in earlier versions of Pulse Audio). I didn't need the Soundblaster, but I had it so I thought I'd use it. A couple of tweaks later and it worked without stutter. A little while later and a patch came out in openSUSE and it was all fixed for me. It did seem like a bad config that was later resolved.

OSS is outdated and has its limitations. ALSA worked, but per-app config can have it uses and I'm sure that there'll be more and more uses for the other features (like moving output, automatic volume adjustment, etc). Maybe PA is a bit buggy, but if people don't test it then it isn't going to get any better.

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

[ta bu shi da yu]

Who the hell cares? Software gets developed, it's actively worked on in a coordinated fashion (more distros are using PulseAudio all the time) and it gets better. It's called progress, without it Linux distros would stagnate.

Re:Useless

[Erikderzweite]

IMO Pulseaudio is great. Finally an easy way to manage several video cards, especially Bluetooth headset. Skipping/freezing issues -- I used to have them once, not anymore (since 0.9.18 IIRC).
CPU usage is also ok, I can't even see pulseaudio in top list.

As for features -- PA is for sound what compiz is for video. I find it very handy.

Re:Useless

[Anonymous Coward]

I don't need a sound daemon. I have FreeBSD. Every sound daemon I tried makes it worse.

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

[makomk]

PulseAudio as a system-wide daemon does work, it's just not recommended for normal desktop use. If you're doing something really exotic, it may make sense. Note that getting ESD support working in system mode requires some monkeying around should you need that.

Re:Useless

[jedidiah]

No, the problematic "it will prevent all adoption BS" are ideas like
"Bluetooth audio" being typical use cases. Even HDMI and SPDIF are a
bit of a stretch but at least they address the relatively common
"HTPC" use case.

Some people have a really strange idea of what should encompass the
basic OS features.

Re:Useless

[Anonymous Coward]

How the hell can a volume control be horrible? It's a fricking slider?

Myself and probably many other people were doing just fine "managing" (i.e. leaving it alone, it was fine) the sound system (or lack thereof) for years before pulseaudio showed up.

Pulseaudio is probably a deliberate attempt to ruin the Linux desktop. Or do you really think that the developers can be that incompetent?

Re:Useless

[Anonymous Coward]

PulseAudio is NOT unneeded.

Maybe not, but you do not provide convincing arguments.

First, Bluetooth audio _sucks_ without PulseAudio.

Why not fix the original stack instead of adding to it? "The tire is flat, let us add another one!"

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

No. KDE 4 has a nice daemon that handles new devices, disconnections and whatnot, without adding another layer in the stack (it interfaces directly with ALSA, even if it is named "Phonon" :-).

So what you do *not* need, is to have a userspace daemon that all the sound passes through.

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

I've talked with ALSA developers that said that per-sink mixing should be possible to implement with dmix (but that is apparently much more work than writing a complete sound daemon!).

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

Why couldn't this be implemented in the existing layers?

Re:Useless

[QuoteMstr]

KDE 4 has a nice daemon

what you do *not* need, is to have a userspace daemon

Confused much?

Re:Useless

[Carewolf]

I've talked with ALSA developers that said that per-sink mixing should be possible to implement with dmix (but that is apparently much more work than writing a complete sound daemon!).

It is possible. Technically it is just a matter of configuration. In a reality it is harder using ALSA because it is not standard behavior like with PA, so application support is minimal. Phonon has similar mixing though in the API, if I remember correctly kmix just isn't using it yet because kmix prefers to access ALSA directly.

Re:Useless

[jelle]

To be ever successful, pulseaudio should be able to run just fine without realtime privileges on a kernel that doesn't have 1000hz timer (etc).

It's fine if it will run better with those features, but it should not run any worse than a system without pulseaudio without them.

For example: If I have a real reason to want a program to have low latency, and run it with realtime privileges, I would not want pulseaudio to sit in its way and have it share real-time priority.

Without pulseaudio I would not have that problem, so it's pulseaudio that is the problem.

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

[harmonise]

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.

The problem is that once it gets close to working, someone will come along and develop a new program that replaces PulseAudio, making tons of promises of functionally. Distros will rip out the working code and replace it with the new less functional code. Meanwhile, the users will be told by the developers how great everything will be once the new code works, even though it's not yet up to the standards of the old code. I've seen this over and over in distros.

Re:Useless

[jhol13]

I constantly run two users (with User Switcher) and it would be nice if the other user forgetting flash would not disturb me (and vice versa).

At the moment (on Ubuntu 8.04) this is not the case.

Another problem is USB memory sticks and CDs. Putting one in will show the data on both desktops and most annoyingly will start two CD players (one on either user).

Re:Useless

[darkpixel2k]

PulseAudio is NOT unneeded.
First, Bluetooth audio _sucks_ without PulseAudio.

You got bluetooth audio working with Pulse? I spent several days dorking around with it and never got it.

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

Never had any problems with the Alsa sound daemon...

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

True

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

True--but like others have said, 'playing audio' would be a nice feature.

Re:Useless

[darkpixel2k]

The idea is great. PulseAudio is an excellent solution for networked audio and thin unix clients.

I have a few thin client setups using Ubuntu 9.04 with PulseAudio. The audio is choppy on every thin client. That's when it's working. Half the time Pulse crashes while playing, changing the volume icon to muted and then refusing to work until the thin client is rebooted.

Sure, maybe it's some strange Ubuntu issue, but it's damn annoying.

Re:Useless

[mcgrew]

I don't know, TFA mentions some features sorely lacking in Windows (and in my own old distro, I guess I need to upgrade). One that really sounds good is, you're listening to a stack of MP3s or an internet radio station and you start a movie, the sound stops in the internet radio feed and starts back up when the movie is over.

Re:Useless

[leoc]

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

It does for me.

Re:Useless

[AdamWill]

carewolf: ah, so sane volume control, device switching, Bluetooth audio support and more are useless on the desktop? I see what you're saying.

Re:Useless

[AdamWill]

you are aware you can quite easily configure an app to output direct to ALSA even if an instance of PA is running, right? Or you can, trivially on any distribution, disable the default routing of ALSA output to the PA daemon?

the only reason that '99% of the answers will be "uninstall PulseAudio".' is that people are idiots. The correct answer is to learn how to configure your system properly. Yes, I know, you learned Unix at your mother's knee 50 years ago and you hate anything that changes anything you knew back then, yadda yadda, whine fucking whine.

Re:Useless

[MrCrassic]

Unless you're using amixer to set your volume levels, they really aren't that bad. there is a GUI equivalent for alsamixer, and it works well and looks good, last time I used it (a few days ago; still use alsamixer on the command line, since it works better with flux)

Re:Useless

[AdamWill]

For a start, it's not open source:

http://developer.opensound.com/opensource_oss/licensing.html: "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..."

For a second, it has absolutely no chance of being merged into the kernel as written, hence little chance of being adopted by any major distribution.

Re:Useless

[Tetsujin]

As long as BS like this is accepted as 'normal', it will never be "the year of the linux desktop".

First, a thousand times over I don't care if it is or is not the "year of the" whatever.

But the point you seem to have missed is this: it is the distribution maintainers who turn the collection of Linux-related software into a coherent system. The point the grandparent post was making was that they weren't getting this right, because default installation of Pulse on these distros was lacking the proper configuration. That isn't "normal", that's a flaw in the distro.

Re:Useless

[Carewolf]

None of those have anything to do with the audioserver. Could be done anywhere else, and ASFAIK they are.

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 (

Re:Useless

[Tetsujin]

"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.

Really, I read that bit and had to wonder if maybe the technically-minded folks were just the ones who were more resistant to using Pulse in the first place...

That said - I haven't given Pulse a real fair shake myself. I tried it once - on top of ALSA, BTW - and I felt like it was bringing me no real benefit, but it was also introducing problems, so I got rid of it. I just wanted to get everything up and running smoothly. In particular I wanted a good solution to the problem of "legacy" use of /dev/dsp on my system. (I believe Alsa doesn't support multiple access to /dev/dsp at present, so a sound server seemed like a sensible solution...) I though Pulse would be a good way to do that, but it turned out to be simpler for me to just go with ALSA. That's worked pretty well - the worst I've come across is occasional failures of Flash's audio support.

But, as I said, I haven't given it a fair shake. I'd like to understand the whole situation better, and see what Pulse can do for me. So one of these days I intend to try it again.

Re:Useless

[msimm]

If it's not ready and causes a large portion of the users to complain or have problems it's nice features don't matter so much. It's probably also worth mentioning reputation, in that a audio server which causes problems might unfairly garner a reputation that will outlast many of it's earlier stage hick-ups.

We bash Microsoft all the time for releasing beta-quality software as retail, but here we are.

It seems like an interesting project that got stuffed into production distributions before it was ready.

Re:Useless

[Anonymous Coward]

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

News flash: "other sound daemons" aren't the only ones that suck, PulseAudio sucks, too. In fact, all Linux desktop sound servers suck. Why? Because it is an inherently flawed idea (with the exception of niche audio processing -- I'm looking at you, jackd, you're cool!).

Windows and MacOS don't take the majority of the CPU time and literally SECONDS of real time to mix two streams! Linux shouldn't either.

We went through this once with ESD and ARTS! Why must we repeat the same STUPID ideas with PulseAudio? I thought we had grown beyond this.

Ubuntu is the big dog in desktop distributions now and they've stupidly thrown their weight behind PulseAudio. If there's ever an opportunity for Debian, it's this. Debian, in general, should be identifying stupid tech decisions implemented in Ubuntu and employ WORKING solutions in Debian proper.

Disclaimer: despite my cynical tone, all the developers involved have my respect and gratitude, we're all pursuing the same goals. Thanks for working to make free software better!

Re:Useless

[DMiax]

No. KDE 4 has a nice daemon that handles new devices, disconnections and whatnot, without adding another layer in the stack (it interfaces directly with ALSA, even if it is named "Phonon" :-).

So what you do *not* need, is to have a userspace daemon that all the sound passes through.

Phonon is a library, it does mostly nothing but offer a sane, thin interface to programs that need none of the complexities of other systems. Which is 95% of all programs, probably.

Re:Useless

[AdamWill]

"For the mundane user, ALSA was doing fine before Pulse came along."

Really? Were you on any user support lists or forums before PA became widespread? How many people did you explain how to set a default sound card to? "Well, first you need to find out what kernel drivers your cards use. Then you need to edit /etc/modprobe.conf and set the index=0 parameter for one of the modules, and index=1 for the other. Oh, both your cards use the same module? Then you're screwed, sorry." Ahh, those were the days...

(and yes, lots and lots of 'mundane users' have more than one sound device.)

Re:Useless

[Anonymous Coward]

Let me sum up what I think your argument is:

Everyone: PulseAudio takes up the majority of CPU time, has high latency, and tons of audio artifacts.

You: If only you had realtime privileges set up properly, PulseAudio could indiscriminately grab CPU time, thus starving other processes and reducing system responsiveness. With all that CPU time, PulseAudio would have lower latency and reduced artifacts.

This doesn't solve the problem! I don't want PulseAudio taking 50%+ of my CPU time just to play a freakin wave file. If you're telling me that the solution to the latency problems is the hack up the Linux kernel so that it will arbitrarily give EVEN MORE CPU time to PulseAudio, then you're not playing with a full deck of cards. The whole sound server paradigm is flawed.

Re:Useless

[Wonko the Sane]

I'd like to understand the whole situation better, and see what Pulse can do for me.

I installed PulseAudio for the first time this weekend to answer that very question.

My main desktop is used by my wife and I for regular internet browsing/email as well as webcam chats with inlaws and running Rosetta Stone under Wine.

PulseAudio lets me route the webcam microphone to the IM programs and the USB headset microphone to Rosetta Stone*. If one of us is listening to music or watching a movie on the speakers and the other one gets a phone call we can easily route the sound to the headset without needing to stop playback.

It's not exactly groundbreaking but it does make life easier.

*Wine support for PulseAudio is somewhat problematic, but solutions exist.

Re:Useless

[AdamWill]

" 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. "

Except that the bugs in ALSA weren't exposed until something - i.e. PulseAudio - started using them. And the bugs exist in multiple different drivers on multiple different cards. If we don't get PulseAudio into actual usage on actual hardware, there's no way of finding the bugs to fix them, and nothing ever gets better.

Re:Useless

[DavidTC]

What the hell do either OSS4 or ALSA have to do with PulseAudio?

PulseAudio is a replacement for asound and esd. It's a sound daemon, not a sound driver system.

It can, at the moment, only use ALSA, but that's not some sort of fundamental requirement. In the long run, I expect PulseAudio will use whatever drivers get used the most, and hopefully at some point even support Windows. (Not for really needed for local use, but useful for networking stuff.)

It's like half the people here don't even know what they're talking about when they talk about PulseAudio.

Re:Useless

[srwalter]

In today's world, OSS4 is open source, it is actively being developed, and it WORKS!

If OSS4 is such a great magic bullet, why hasn't it it included (much less default!) in a single distribution? Why isn't it part of the stock kernel package? Until both of those things are the case, OSS4 will continue to be an also-ran, just like devfs2 and GGI.

Re:Useless

[Grishnakh]

I think this question was answered above. It's not in any distros, because it's not part of the kernel. And there's some issues in getting it included in the kernel (some of the drivers aren't open-source yet because they were written under NDA, some are closed-source because they're written by the mfgrs). Hopefully, with a little time, these issues will be resolved.

Re:Useless

[AdamWill]

any interface which presents over thirty different sliders on many cards, many of which aren't actually really sliders you can / should interact with, is not a very good idea.

Re:Useless

[segedunum]

The problem is, Linux audio is broken and it HAS to be fixed. PulseAudio just exposes the problems in it.

By making it even worse with an overly complex architecture that has no hope of being improved?

Re:Useless

[Runaway1956]

Dude, you answered your own question, without realizing it.

"What the hell do either OSS4 or ALSA have to do with PulseAudio?"
"It can, at the moment, only use ALSA,"

If you read, you will find that Pulse and ALSA have failed to provide a decent user experience for some users. Replacing Pulse doesn't necessarily mean replacing drivers - but many of us found that OSS4 was the way to go.

"In the long run, I expect PulseAudio will use whatever drivers get used the most"

It isn't the drivers, so much as, PulseAudio isn't doing the job that people need. I mentioned that Pulse was unable to mix sound from virtual machines and the host machine. Others have problems mixing from different sources. Pulse fails to deliver what some people need. OSS4 is a working alternative.

Re:Useless

[AdamWill]

The note that it is not entirely open source post-dates those news posts and is still accurate to the latest versions of OSS, as far as I'm aware. The source code does not include the bits that are described as proprietary in the note I quoted.

The full text is interesting (though I didn't quote it for reasons of brevity) because it makes clear that 4front don't see this as a one-off, but as an _ongoing state of affairs_: "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."

Thus even if they ever do manage to make an OSS release that's entirely open source, there's no guarantee any future OSS release will be. Which is another reason it's very unlikely to be accepted into the Linux kernel and hence be used by any significant distribution.

Re:Useless

[Per Wigren]

Wrong. It doesn't need that much CPU time, it just needs its CPU time at very exact intervals. Given realtime privileges it can preempt at those very exact intervals without needing to hog the CPU in between.

Re:Useless

[Runaway1956]

I think I follow your reasoning - and I think you are missing something. Let's try this, and see if we are talking about the same thing:

ATI won't open source THEIR drivers either. But, we have a variety of drivers for ATI which are open source. As the end user, I can decide whether I want to use the FGLRX driver, or the proprietary Radeon driver. In most cases, I go with the Radeon, because it gives a little better performance than any open source alternative.

The parallel to OSS4, is, I downloaded source code from 4Front, compiled and installed it. It works fine. But, apparently 4Front offers a binary, which contains proprietary code, and which offers some "enhancements". As noted, I'm perfectly happy with the results of the "open" source that I downloaded. Why should I download the proprietary portion?

IMO, that code which has been licensed under GPL and BSD is sufficient. If/when the rest of the code is open source, maybe I'll find that I've been missing something - though I can't imagine what. The open sourced portions of that code can, and probably should be, put into the distros as an alternative. And, the proprietary binaries should be too.

I can get those Radeon drivers through the repositories, after all.

Are we any closer to a meeting of the minds, or is there something we simply disagree on? Please understand, I'm not trying to be an ass. ;^)

Re:Useless

[Bent Spoke]

A bigger issue is a desktop misbehaving because memory is being slurped up (ie. 1Gig) by pulseaudio, even when we're not explicitly using sound! For example, Firefox pauses all the time, OpenOffice takes forever to startup, etc, etc.

It's this collateral disruption that has many hot under the collar.

Re:Useless

[Cyberax]

Nope. PulseAudio has a very sane architecture.

In fact, OS X and Windows 7 have similar architectures.

Re:Useless

[Windwraith]

You forgot to mention the streams are stored in memory being ~64mb each...since I removed Pulse I haven't hit swap again.

Re:Useless

[Ant P.]

the only reason that '99% of the answers will be "uninstall PulseAudio".' is that people are idiots. The correct answer is to learn how to configure your system properly.

Remind me, who is the target audience of Pulseaudio again? Not me, I already know how to configure my system properly. It's built with USE="-pulseaudio".

Re:Useless

[AdamWill]

the OP was trying to do something rather unusual, hence the 'target audience' argument is invalidated. The target audience you're thinking of isn't likely to be trying to run mpd from a console.

Re:Useless

[andreww591]

Most modern Unices don't need a sound server, because they have a mixer built into the sound driver. Linux is the only commonly-used Unix that still has a single-open sound driver, as far as I know.

Re:Useless

[Anonymous Coward]

Pulseaudio has been default on Fedora since Fedora 8. Tell me, how long does it take to get it right?

Re:Useless

[segedunum]

No, Windows and OS X do not have similar architectures so I wish people wouldn't repeat that bullshit. This by no definition is a sane architecture that has a hope of being reliable:

http://en.wikipedia.org/wiki/File:Pulseaudio-diagram.svg

Re:Useless

[AdamWill]

"Pulseaudio has been default on Fedora since Fedora 8. Tell me, how long does it take to get it right?"

well, that's kind of a stupid argument. NVIDIA video cards have been around since the 1990s and we didn't get those 'right' yet. ALSA was the default for the last eight years and that ain't right either. Neither GNOME nor KDE are apparently 'right' or else they wouldn't both be getting major revisions. I could go on, but you get the point. Software has this habit of getting improved and revised over time. It's never 'right'.

Re:Useless

[Anonymous Coward]

PA is for sound what compiz is for video.

So PA is unneeded shit which sucks ass?

Re:Useless

[FrankieBaby1986]

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.

Agreed. I'm a 4 year linux user (Noobuntu- shrugs), but pulseaudio is definitely my biggest annoyance.

In windows XP and Vista, one can Fast User Switch while playing audio, which plays through uninterrupted. This is the behavior I would expect.

Re:Useless

[jedidiah]

> and yes, lots and lots of 'mundane users' have more than one sound device

That is very arguable.

Re:Useless

[Anonymous Coward]

pulse audio sucks so big it is untrue. it needs another 3 years work before it even get to see the light of day i canned it on here all the audio works they way it should now think it needs a rename to PPA "Piss Poor Audio"

Re:Useless

[Cyberax]

Vista _has_ a similar architecture:
http://blogs.technet.com/photos/blog_photo_gallery/images/450100/original.aspx

(from http://windowsteamblog.com/blogs/windowsvista/articles/450038.aspx )

I.e. mixing and processing is done in userspace.

Such architecture is great, because you can do a lot more tasks sanely in userspace than in kernel.

Re:Useless

[Anonymous Coward]

PulseAudio is specifically designed to handle this case. Using Ubuntu 9.04, it seems to work. (Ubuntu 9.04 is the first version of Ubuntu where PulseAudio is starting to work right.) My wife and I are sharing an Ubuntu 9.04 computer, and if I leave music playing when I do the fast-user-switch, the music cuts out when the switch happens, and comes back when I switch back.

I guess none of the PulseAudio-haters care about this use case; they all say PulseAudio does nothing of any value.

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

[L4t3r4lu5]

I take it, from the necessity of a Slashdot article, that PulseAudio is currently the latter?

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

[DangerFace]

Currently PulseAudio is one of the range of audio solutions on Linux that is a bag of crap. I use Linux myself, and very rarely run into problems, but when I do the solution is usually to turn off PulseAudio. Essentially it suffers from the old Linux problem of doing lots of cool stuff very well, but doing the very basic stuff (like taking some input and transferring it to some speakers) quite badly.

I genuinely feel that audio is what is really holding back Linux on the desktop, because there is not one stable API but several unstable ones. Of course, audio is a bloody hard thing to get right, and not something most developers are going to spend a lot of time on, but it's important dagnabbit!

Re:Durability in the face of errors

[Anonymous Coward]

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

Drivers generally are bad. Not just sound cards.

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.

Microsoft didn't do it for that reason. It ditched DirectSound because... it bypassed the DRM subsystem in Vista, and Microsoft had no way of fixing it. Pure and simple. DirectSound was a software "layer" as much as any other subsystem. Microsoft killed off all the old sound APIs for ONE reason: Digital Rights Management to appease the content crowd.

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

[Anonymous Coward]

I've seen too many instances (and am guilty of some myself) in our own code base of programmers expecting to never have errors occur in the way that they do. This is one fundamental problem with the 'try... catch' model of error handling - the programmer still needs to carefully check each piece of code and pass the errors up to the appropriate level to be handled without bombing the app.

One of the biggest problems we face in my development environment is that the code we service is 20+ years old and in a multitude of different languages, some of which don't really support exception handling at all, thus making error handling all the more difficult. Often we are limited to a return code mapped to an enum... especially in some of the error-prone low-level numeric routines we employ.

I imagine developing sound drivers that PWWO is similarly tricky. Lots of low-level driver code to interact with and very little idea what it's actually doing under-the-hood to produce the error codes it spits out. In fairness, I have not ever used PA - but I imagine that many bugs can be justified (although, of course - should still be fixed) by the lack of meaningful errors from drivers it interacts with. To the developers of PA I say, best of luck - I know a bit where you're coming from.

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

[QuoteMstr]

Most cards were (and are today) little more than buffers you could write data in to to be played.

Yep. But some weren't. Sound card quality started a long, slow decline once Aureal folded. Keyboards and sound cards are two pieces of hardware that were better ten years ago. And you'll take my Model M and my AU8830 [with its hardware mixing] from my cold, dead hands.

the graphics subsystem was moved in to user mode

That's not entirely correct. What actually happened is that the kernel retained the mode-setting functionality functionality and the low-level command queuing infrastructure, but the higher-level logic, CPU-side graphical calculating, shader compiler, etc. moved to userland.

Re:Durability in the face of errors

[makomk]

Aureal folded

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

Re:Durability in the face of errors

[Anonymous Coward]

Microsoft didn't do it for that reason. It ditched DirectSound because... it bypassed the DRM subsystem in Vista, and Microsoft had no way of fixing it. Pure and simple. DirectSound was a software "layer" as much as any other subsystem. Microsoft killed off all the old sound APIs for ONE reason: Digital Rights Management to appease the content crowd.

I'm not sure if this is just a troll aiming for exactly this response, but I'll bite.. everything here is wrong/FUD (take your pick). DirectSound API is still there, not ditched/killed. This has nothing to do with DRM. Microsoft took hardware acceleration out of DirectSound, and moved sound processing to software, to create a more robust model.

Re:Durability in the face of errors

[Anonymous Coward]

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.

Pleeeeeeease please please please tell me that somewhere else in the article the guy makes reference to how backward-compatible and transparent PulseAudio is supposed to be. Please please please please. The irony is just begging to come forth that a program that didn't crash the sound system before breaks the transparently backward-compatible APIs used in the new stuff and that the applications need to be fixed.

Mmm, it's going to be soooo delicious. I can almost taste the irony now...

Re:Durability in the face of errors

[shutdown -p now]

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

Why does OSS seem to fare much better than ALSA at that, though?

Hence sound cards are one of the leading causes of blue screens in windows 9x and XP.

I've yet to witness a single BSOD that would mention a sound driver. Most that I've seen have to do with video drivers.

Re:Durability in the face of errors

[BikeHelmet]

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.

OpenAL was made by Creative? Interesting.

I know many games choose to use it. Seems like a solid API - seems to work well on anything.

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.

This isn't strictly true. The problem in XP is unloading graphics drivers. If you get locked to the VGA graphics driver, you can point it to an nVidia driver from devmgmt.msc, install that driver, and immediately have access to full-resolution 32bit colour and hardware acceleration for games. Without a reboot.

But uninstalling the old nVidia driver before installing the new requires at least one reboot.

Note: Have not tested this on ATI hardware.

Re:Durability in the face of errors

[Anonymous Coward]

The API was ditched... it doesn't get used now because it's completely fucking useless BECAUSE it of design decisions that didn't allow DRM. The idea of not using "hardware", and instead use "software" for extra robustness is so completely wrong it's almost amusing.

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

[pembo13]

> bugs are being ignored.

That's a blatant exaggeration

Re:The problem isn't the idea

[Anonymous Coward]

> bugs are being ignored.

That's a blatant exaggeration

"Bugs are being ignored" isn't an exaggeration, since if there's at least 2 bugs that the developers haven't addressed or explained why they don't want to address them, then the statement is correct. It is, however, completely non-specific and vague.

Re:The problem isn't the idea

[Anonymous Coward]

I fixed pulse audio by installing a beta version of Linux(Opensuse) and buying a 4GZ i7 machine. It still sucks, but at least it doesn't skip every 20 seconds like on my Athlon box. So.. there's that.. I guess. Yea.

Re:The problem isn't the idea

[Anonymous Coward]

Yeah they're not being ignored. They're filed under "WORKSFORME" or "SOMEONE ELSE'S PROBLEM" or "PLEASE REPORT PROBLEM AS 10 DIFFERENT BUGS PLEASE".

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

[alukin]

Properly implemented idea is jackd. Pulse is bad idea and bad implementation. All professional sound tools use jackd, no on wants pulse.

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.

Re:The problem isn't the idea

[Anonymous Coward]

You can easily find recent PA-related horror stories in Fedora bugzilla (by people running fedora-devel, ie the latest bleeding edge PA on the preferred distro of PA's author).

These reports are usually closed when the reported gets too disgusted to carry on.

Re:The problem isn't the idea

[harlows_monkeys]

The guy who wrote Jack says you are wrong.

Re:The problem isn't the idea

[alukin]

He says many things and he is just very polite guy. I am not so I dare to say that PA is total pain in the a**.

Re:The problem isn't the idea

[Pecisk]

First of all, using Fedora as stable release for desktop is a joke, seriously :) It is good for trying out bloody edge things, but nothing more.

PA has improved very seriously during last year, and CPU problems have gone at least for me and Ubuntu users I know. Some new issues have popped up though, but I think someone could say that those bugs you mentioned are not valid anymore. And believe me I was very angry how PA came into existence (buggy as hell, forced in default install), but now I have to admit that Lennart have proven some of his points (I really can't imagine desktop without some of PA features I have used to. And it is not a network streaming). Of course, it would be better if he avoided flame wars with users and other developers. Attitude matters.

Of course, you are entitled to have your own opinion.

Re:The problem isn't the idea

[bill_mcgonigle]

But because PulseAudio is visible, and because an old distribution once shipped with a CPU-eating PulseAudio, it makes the perfect scapegoat today.

I'm sure some people are scapegoating it, but there are still real problems. My netbook is a mess. If I wake from sleep I need to -k and --start pulseaudio. Then the sound works again, but now I have to restart my apps. Sometimes it drops into a stuck 2-second infinite loop, and when I -k --start, things come back. I've filed bugs, posted backtraces, etc. and so have many, but no fixes have emerged.

It's a necessary idea, but the project seems terribly under-resourced, so it's catching lots of heat. Fedora also made it default far before it was ready, which is not the developer's fault.

Re:The problem isn't the idea

[AdamWill]

"Fedora also made it default far before it was ready, which is not the developer's fault."

Given that Lennart is in fact the Fedora PulseAudio packager, you could say it partly is. :) But see an earlier comment of mine for an explanation of why PA was made default at the point it was.

Re:The problem isn't the idea

[bill_mcgonigle]

Given that Lennart is in fact the Fedora PulseAudio packager, you could say it partly is. :)

I don't understand - isn't this a FESCO-level decision?

But see an earlier comment of mine for an explanation of why PA was made default at the point it was.

Yeah, I get that application developers need to be pushed along at some point, but the application-facing aspect of PA and the kernel/driver-facing aspect can be thought of as separate efforts. If basic things like sleep were working, then the users would be supportive and encourage the app developers to get on board. Instead, we have this Slashdot article and the general attitude that PA just needs to be uninstalled, which is a shame.

Re:The problem isn't the idea

[AdamWill]

if by 'sleep' you mean suspend, that's not a general problem. Or, at least, it Works For Me (tm), on a Sony laptop (not renowned as a source of super-friendly hardware). I can suspend / resume as much as I like, no audio troubles.

Yeah, it's a FESco decision, but on the other hand, if Lennart had fr'instance said 'of course we shouldn't push it by default, what are you, _nuts_?' it probably wouldn't have happened.

"Yeah, I get that application developers need to be pushed along at some point, but the application-facing aspect of PA and the kernel/driver-facing aspect can be thought of as separate efforts."

But if we don't have people actually using PA by default - i.e. hook applications into it - it's not getting any use, and none of the bugs would get exposed. It'd be 'there' by default but not actually being used at all.

Re:The problem isn't the idea

[bill_mcgonigle]

if by 'sleep' you mean suspend

OK, yeah, I was using KDE terminology. ;)

that's not a general problem. Or, at least, it Works For Me (tm), on a Sony laptop (not renowned as a source of super-friendly hardware). I can suspend / resume as much as I like, no audio troubles.

It's probably fair to say it's not a problem across every driver. I'm using Intel audio, integrated.

Yeah, it's a FESco decision, but on the other hand, if Lennart had fr'instance said 'of course we shouldn't push it by default, what are you, _nuts_?' it probably wouldn't have happened.

Sure, but I'd expect far more often for a developer to think his package is ready than the steering committee (its raison d'etre in large part).

But if we don't have people actually using PA by default - i.e. hook applications into it - it's not getting any use, and none of the bugs would get exposed. It'd be 'there' by default but not actually being used at all.

I may be misunderstanding - do apps not go through PulseAudio unless they're re-written to use it? I understood it transposed itself in the ordinary case, but provided great advantage in the optimized case. Based on that, I assumed it would have been possible to get Pulse working first with its hardware/kernel interface, and when that was ready to go get apps optimized. My impression may well be incorrect.

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?

Re:Why do I care where the bugs are?

[Wonko the Sane]

So what's the benefit of PulseAudio again?

Besides your regular set of speakers you also have a webcam with a microphone and a USB or Bluetooth headset and you want the inputs and outputs to get routed to the correct applications.

Re:Why do I care where the bugs are?

[Skapare]

ALSA isn't working very well for me. How do you make it work to have 3 applications play audio concurrently?

Re:Why do I care where the bugs are?

[cynyr]

dmix, it should just work if it doesn't you may need to set it up... google == friend

Re:Why do I care where the bugs are?

[keithjr]

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.

Actually I just set this up yesterday with padevchooser. It was remarkably intuitive once I had PA set up correctly. The problem, of course, is that setting up PA in general is an awful experience that creates a boatload of issues with many apps. Once it's up and stable, however, using it to pipe sound over the network seems to work like a charm.

Re:Why do I care where the bugs are?

[ThePhilips]

I have seen some distros come with commented out dmix in ALSA global config file. That might be the cause.

Just like with PulseAudio, mixing in user space is latency-prone, contributing to jitter/etc. Since most cards support H/W mixing (gp's one apparently doesn't) they might have decided to disable by default.

Re:Why do I care where the bugs are?

[Malibee]

I personally find the networking aspects of Pulse to be quite handy. I have mpd running on my file server, streaming to a PulseAudio server on my media center (Ubuntu Jaunty). I also have it stream to my desktop.

Using the nifty iPhone app MPod, I can control my playlist from the palm of my hand, in a fashion that beats a universal remote all hollow, since I can actually see the playlist I'm queuing, instead of having to squint at the screen (yes, I have a small display, don't laugh) or get in position to view the screen. And there's nothing like being able to switch tracks while you're on the can (there's a joke in there somewhere, but I can't quite find it).

I hope to one day figure out some sort of motion sensing or proximity detection mechanism to selectively enable/disable mpd outputs so that I can be listening to music on my sound system, and when I leave the room and into my office I can pick up my headphones, and the same playlist will be playing there automatically. Sort of like motion controlled lights, except it's sound.

I'd also really like to see is some kind of mashup between vlc's remote control app and Moovida and this MPod app, so I could have a centralized media center with a truly universal remote control. Apps work on the iPod Touch too...

Re:Why do I care where the bugs are?

[Anonymous Coward]

Make a shell script?

Re:Why do I care where the bugs are?

[Skapare]

Mixing could be done 2 general ways (plus many detailed ways within these 2 categories). One is to allow multiple opens of the audio device node (details: either the hardware can mix multiple audio streams coming into it, or the driver can fake it). The other is a user space program the applications make some kind of connection to (details include what protocol, negotiations, format, priority, etc).

Hardware with a long queue/buffer can help against jitter, dropouts. It would need to have an HPI that allows clearing the buffer so you don't have several minutes of audio still playing when you kill the app. A kernel driver can fake this, too, within the limits of what is appropriate in the kernel (no point if the hardware can do it).

Re:Why do I care where the bugs are?

[ThePhilips]

The whole point of the "Sound on Linux" fiasco is that drivers in Linux are not allowed to fake it. ALSA is designated to serve only as an interface to the sounds card, exposing everything to user space (regardless whether it's worth it or not).

OSS in comparison does mixing in kernel (not that sound data rate was that high anyway) what makes it 100% transparent to user applications. Compared to ALSA, OSS exposes to user space a consistent generic audio interface.

Re:Why do I care where the bugs are?

[Anonymous Coward]

So what's the benefit of PulseAudio again?

Much better battery life for notebooks and other portable devices:

http://0pointer.de/blog/projects/pulse-glitch-free.html

Seamlessly handling hotplugged audio devices.

Smoothly handling sharing of audio hardware when doing fast user switching.

Providing software mixing and sample rate conversion for modern motherboard audio devices that very well might support only a single stream of audio at 48000 Hertz and 24-bit samples.

PulseAudio on Linux makes sense for exactly the same reasons Apple added a userspace sound daemon in OS X and Microsoft added a userspace sound dameon in Vista/Windows 7.

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?

[Anonymous Coward]

As I recall, there were various free OSS drivers in the kernel, but for others you had to buy the commercial version, not a happy state of affairs. Add to that the API was becoming more limiting and not reflecting some capabilities of current hardware. So we get the new, shiny, ALSA. Linux only, but the momentum was there. Everyone loves a re-write of something fun. Unfortunately its APIs suck donkey ass (technical term) and is generally a pain to set up right. Oh, you want to configure your asoundrc to have dmix work for your hw:3:2 device. And don't forget to load the modules in the right order or your default card will be your onboard video's HDMI port. Argh.

By having OSS API compatability it managed to get accepted. The new OSS API is mostly an extension, except for the mixer - which is a shame, but hey, modern hardware is very wacky. Inputs can become outputs, dozens of switches, etc. Hmm, makes you wonder how windows manages to still show you the CD, Wave/PCM, and master volume though.. Note: OSS is basically the product of one bloke, who at last glance was still trying to get paid for his work. Surprised some distro doesn't just hire him. And no, that's not me.

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?

[InEnacWeTrust]

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!

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.

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.

Re:Why is OSS no longer in the kernel?

[Anonymous Coward]

Amen.

Re:Why is OSS no longer in the kernel?

[domatic]

I followed and read that. It is one of the most stupid things I've ever read in my life. 4Front believes they can restrict the use of OSS4 on Linux only to GPL apps. In their view, if you fire up Doom3 and play the sound through OSS4 then you are in "violation the terms we choose to distribute under". They furthermore believe they can impose this restriction in addition to the GPL. Even RMS doesn't have such an expansive idea of what incurs GPL restrictions. Come to think of it, the GPL goes to some length to explain that restrictions only apply to distribution and not to mere use at all.

I can't see that anyone other than a paying 4Front customer who has accepted a proprietary EULA has any rights to use OSS4 at all. Their public statements + GPL would not appear to be a viable license to either use or distribute.

Re:Why is OSS no longer in the kernel?

[Anonymous Coward]

Where do you see the problem? They are talking about using the GPLv2 for kernel code (Linux kernel code that is, BSD and Solaris get CDDL). You know, just like the rest of the kernel. Then they talk about companies needing a commercial license for using OSS4 in a commercial environment (like QNX perhaps).

Nowhere do I see any claim that an application being infected. With OSS, all an application needs to do to play sound is fopen("/dev/dsp","w"); and writing to that file descriptor. Noone ever claimed you need a commercial license for using fopen.

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/>

Re:Among other distros, Ubuntu...

[dargaud]

How do you stream music from a Linux box to a portable (say Android) player ? I could only find poorly documented libraries or very complex daemons oriented more towards making a web radio than an on-demand server.

Re:Among other distros, Ubuntu...

[Anonymous Coward]

whenever I move away from my wireless access point at home [...] my sound stutters

The author of PulseAudio has gone to some great lengths[1] to make sure that PulseAudio is running at realtime priority, to make sure it doesn't drop packets of audio, i.e. stutter. Ubuntu has not enabled realtime priority for PulseAudio yet[2]. The network driver is a prime source of system slowdowns; I'll bet if you were to move your mouse pointer around as you move away from your wireless access point, you would see the smooth motion of the mouse turn into stuttering too.

I hope PulseAudio gets better in Ubuntu 9.10!

[1] He went so far as to champion a patch to the kernel, which allows giving realtime priority to a single process; if that process forks off any children, they do not inherit the realtime priority. This way, PulseAudio can be given realtime priority, but cannot be used to effect a Denial-of-Service attack against its host computer.

[2] http://0pointer.de/blog/projects/pa-in-ubuntu.html

My bug reports were ignored!

[HRbnjR]

I think it is an absolute disaster, and outlined all the problems I had with it under Fedora 11 at https://bugzilla.redhat.com/show_bug.cgi?id=506213 and was totally ignored.

Re:My bug reports were ignored!

[sjames]

I looked at your bug report, and it was NOT ignored. You were asked to break it out into individual bugs and file them against the actual offending software.How can it be "totally ignored" when the primary developer engaged you in a conversation and suggested where the bugs should actually be filed (meanwhile indicating that one was fixed in a new release)? One project implementing crazy workarounds for bugs in another project is the road to madness.

Perhaps it was not responded to as you would prefer, but that's not the same as "totally ignored".

Re:My bug reports were ignored!

[AdamWill]

Your definition of 'totally ignored' is an interesting one: "Comment #6 From Lennart Poettering (lpoetter@redhat.com) 2009-08-19 11:29:50 EDT (-) [reply] ------- Private Nate, please file seperate bugs about seperate issues. Please file your bug #1 against gnome-media. Your bug #2 is probably a duplicate of bug 506075. Your bug #3 is probably fixed in F12. We changed the mapping between percent/pixels and actual dB to make it more natural. Please file your bug #4 against rhythmbox. Your bug #5 is already filed. I will ignore all other issues mentioned in comments here. So please: seperate issues need to be posted in seperate bugs. And dn't hijack bug reports by adding comments unrelated to the original topic. Thanks. I will close this now." Man, if that's being totally ignored, cut me a slice.

The year of...

[Anonymous Coward]

Next year will be the year of (working) audio on Linux...

Re:The year of...

[Tetsujin]

Next year will be the year of (working) audio on Linux...

My audio has worked for years...

Now, if I were regularly using USB headsets, webcam mics, bluetooth headsets, HDMI audio out, etc., then the configuration issues would be more of a problem. As it is, though, I run an ALSA program and sound comes out.

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.

Re:The uninformed must improve their deficit...

[Syniurge]

If you call crackling system sounds on every computer I've ever tried Pulse Audio on as a "good state".

All I know is that if you take a look at the "alsa-utils" Ubuntu init script, it shouldn't be PulseAudio that horrifies you anymore.

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....

[complete loony]

Even in windows 7 the sound interface sucks. I have a separate headphone and speakers audio device. But with the window sound api, each application needs to provide it's own configuration interface to choose which device the sound comes out of. And most applications don't bother to provide one and just use the default device making it impossible to select where the output goes individually.

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....

[Max Romantschuk]

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.

I'm going to quote myself here:

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'm guessing you're all set up in that sense. I never said it's not possible, I just said I'd rather invest my free time in using working apps on Windows than finding out which apps I can get to work on Linux.

Care to make recommendations, by the way? I'm looking for something self contaied, similar to Propellerhead's Reason or Jeskola Buzz.

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.

Re:Too many choices....

[PitaBred]

The difference between Linux and FreeBSD is that Linux is intentionally designed to have flexibility. Does Ubuntu have 4 wireless stacks? Does Fedora? Or did they choose one and start working with it? You're comparing apples to oranges... Linux as a kernel is just a base for distro's to build off of, to choose what parts and settings they want. FreeBSD, you get it their way, or take the highway. I'm not saying FreeBSD isn't good, but it's not as flexible.

Re:Too many choices....

[allquixotic]

Max, I also like to play around with stuff, and I feel your pain that Foo Application has a relatively poor chance of using the APIs that your sound stack supports. But, there are actually very many ways to allow applications to use different audio APIs at the same time, in parallel, by chaining together multiple APIs or sound servers. This is worst solution in terms of performance, but the best solution in terms of compatibility. With the right configuration, 99% of sound-using apps will "just work", regardless of what API they use.

Check out my recent-ish blog article on this: http://tiyukquellmalz.org/blogs/blog5.php/2009/08/23/dreaming-of-universal-audio-stacks

Re:Too many choices....

[allquixotic]

The problem in this thread seems to be "I want to install ANY audio-using application and have it Just Work (tm)". This is a more pragmatic wish that has nothing to do with the theoretical arguments about the One True API that have been raging for years.

From my perspective, there is no One True API. As long as multiple audio APIs exist, applications that use them will too. This is a fact of life. To accommodate this, we have several choices:

1. Parts of the sound stack can natively support legacy APIs, allowing us to seamlessly move from the old to new. Example: PulseAudio supports ESD API.
2. Parts of the sound stack can forward audio from one layer to another, be it from the "old" to the "new" or vice versa. Example: ALSA forwards to PulseAudio using libasound_module_pcm_pulse; PulseAudio forwards to JACK using module-jack-{sink,source}.
3. A direct route is neither here nor there, but a multi-hop route is still feasible (example: OSS Proxy -> PulseAudio -> ALSA).

I go through a significant amount of theorizing to argue why it is desirable to have such a configuration, and then make an attempt at actually defining and explaining how to setup such a configuration, on my blog: http://tiyukquellmalz.org/blogs/blog5.php/2009/08/23/dreaming-of-universal-audio-stacks

I just want to add that I am neither pro-PulseAudio nor anti-PulseAudio. There are applications that use the PulseAudio API particularly well -- for instance, Gstreamer and Skype 2.1 Beta. For these apps, PulseAudio works very well, so I see no reason to exclude PulseAudio from my sound stack. As long as it is useful, I will include it as part of my sound stack. _Part Of_. The other parts are designed to take care of audio APIs and use cases that PulseAudio alone cannot handle. Unless Lennart wants to implement every last audio API under the sun natively in Pulseaudio as a module, just as he did with ESD, then I don't think I will ever arrive at a situation where PulseAudio -> ALSA is the full extent of my sound stack -- especially not while popular apps out there still use APIs of JACK, OSS, etc.

Re:Too many choices....

[Anonymous Coward]

Compare with FreeBSD's ifconfig

What is the first enumerated ethernet interface called on freebsd? Hrm, what? Oh, you don't know. Depends on the hardware? Well, that's just wonderful.

Call me back when you have eth0 you fricken BSD primate. ethtool/ifconfig split is for a good reason. One handles the low level hardware settings, the other handles addressing. On BSD you just have one command and it sucks. User asks "how do i change the duplexity of the first ethernet adapter on the system?"

Linux answer: use ethtool on ethtool0
FreeBSD answer: well, i'd have to look at your system....

FreeBSD elitism is so 10 years ago.

Re:Too many choices....

[Yfrwlf]

I've watched my roommate struggle with exploring new Windows sound editing and composing programs. On most any system you have to try things out, find out what works, and works easily, and what you like. Yes, there are a greater number of professional sound editing and composing programs for the other major OSes, obviously, so your selection of good ones for Linux will be fewer. After you learn which ones you like and are the easiest, if you do (which you may not when comparing to audio programs for other OSes), of course you'll then be spending time playing with editing and composing audio instead of looking for and tinkering with new programs. ^^

Creeping featuritis

[ponos]

I have 2 sound cards and Pulseaudio has only given me great frustration. Not that Alsa is much better, but at least I hear something from the speakers. While I respect the work of the developers, they should probably get to the stage where everything works as intended with minimal features and then start adding complexity.

Re:Creeping featuritis

[Anonymous Coward]

"I have two sandwiches with cheese, and the cheese as given me a great belly-ache. Not that the butter is much better, but at least it doesn't give me diarrhea . While I respect the work of the cheesemakers, they should probably get to the stage where their product is digestible with a minimum of complications."

Frankly speaking, adding e.coli to the cheese, with the excuse that it'll be fine if you boil it thoroughly (set your kernel tick to 1kHz) before usage, is completely wacky.

(Behold! No car analogy included!)

Re:Creeping featuritis

[Tetsujin]

(Behold! No car analogy included!)

I think you're vastly underrating the merits of the car analogy.

Who knew?

[PCM2]

Lady Gaga apparently uses Linux.

Re:Who knew?

[PopeRatzo]

Lady Gaga apparently uses Linux

But not on her computer.

Re:Who knew?

[Anonymous Coward]

But not on her computer.

On her muffin?

Re:Who knew?

[Tetsujin]

Lady Gaga apparently uses Linux.

No no no... It's Lady Mega and Lord Giga... And when they use Masterforce, they transform and combine to form Overlord.

It may be buggy...

[AlgorithMan]

It may be buggy (and by now I deactivate it on every machine that I administrate) but in the long run, I think we NEED something like PulseAudio and it really IS a good idea, because that is what you need if you want audio-forwarding for remote-sessions (like the X-Forwarding in SSH)

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.

Re:It may be buggy...

[dwater]

> the other two major OSs have

The *other* two? Since when was Linux a major OS?

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:It may be buggy...

[Anonymous Coward]

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.

I totally agree with above post. I don't think PA should be more than a simple sound system. Working and stable. If you want network transparency and autoforwarding you should use other apps.

Re:It may be buggy...

[carnalforge]

I started using pulseaudio exactly for the network transparency. I have an old laptop with a brocken screen and a wireless, installed a minimal gentoo in that and pulseaudio and i use it as a gateway and keep it konected with my speakers. My main laptop is configured to send sound automatically at the first one when it's reachable. There are some issues (sound clutters occasionally, seems related to the wifi card actually not pulseaudio itself) but works for me.

Re:It may be buggy...

[Anonymous Coward]

We should focus on creating solutions that are looking for problems. Remember when the UNIX philosophy was build a tool to do one job and do that one job well?

Re:It may be buggy...

[dave420]

I totally agree with what you're saying, but I wouldn't have put that 'other' before 'two major OSs', as it's far from correct. I love linux, but let's not pretend it's a major OS just yet. One day, but not yet.

Re:It may be buggy...

[gbarules2999]

Since the invention of the server?

Re:It may be buggy...

[AlgorithMan]

since Linux got 14% marketshare in the servermarket?

Re:It may be buggy...

[AlgorithMan]

I agree that PA is very buggy. I agree that normal users won't need it. But people say they had "networked" audio without PA and that is utter bullshit! they have file-access protocols and read the audiofiles over the net to play them locally (the player runs on your machine, it just reads the file from the server) whereas Pulse enables you to run the player on the server and get just the output on your machine. If you ever digged into the X-forwarding of SSH, you know what I mean. that is a friggin awesome technology and I'd be happy to have that functionality for audio as well (if it's stable).

yes, it's buggy - it's buggy as shit and it has a long way to go, but I'm happy that someone does this, because if you really think it to the end, a server/client architecture (like X has) really is the better idea.

PulseAudio / Normal Audio = X-forwarding / VNC

Re:It may be buggy...

[onefriedrice]

like the other two major OSs have.

Even FreeBSD did the right thing after OSS was closed by building upon what they already had, and sound works much better on that OS because of it. Linux is essentially the only mainstream operating system which is still plagued by audio problems which were solved years ago by everyone else.

Re:It may be buggy...

[amRadioHed]

I think there are a lot of server administrators and cellphone manufacturers that would disagree with you. It may not be a major desktop OS, but it's certainly a major OS.

Re:It may be buggy...

[Belial6]

Exactly. I quick count and it looks like I have 7 devices that actively running Linux in my home. I have 6 that run Windows. While many people might consider this to be a lot of computing devices, it is only the number of Windows machines that they would really be surprised to see.

Re:It may be buggy...

[Anonymous Coward]

If I plug in USB speakers, I expect the sound streams to be routed out the speakers, like if I plug in headphones. If I had Bluetooth headphones, I would like the same thing to happen. Pulse might seem overengineered and worthy of hate, but it solves these problems much nicer than they can be solved with in kernel drivers.

Re:It may be buggy...

[Anonymous Coward]

Most users don't notice latency problems. The commonly used Windows sound APIs have relatively high latency, because for a vast majority of applications a sufficient amount of data can be buffered.

High latency is a killer for sound playback in response to realtime events, such as twitch games and music production software. On Windows, these programs generally use a lower level sound API that bypasses general purpose software mixers (ASIO) to avoid the latency overheads involved. On the down side, the software needs to do its own mixing, and sound devices cannot be easily shared. On Linux, JACK is a specialised audio server for synchronising and streaming low latency audio.

PulseAudio is good for the general case, although badly implemented in some distributions. By being in userspace, the user/distributor has more control over mixing policy. I also read somewhere about developments in PulseAudio that use a different buffering strategy to improve latency.

The separation between low level audio drivers and high level mixers needs to be maintained. Both need to be stable.

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.

Re:Distribution problem

[amRadioHed]

Is there anything that Ubuntu is the best at integrating?

Re:Distribution problem

[Anonymous Coward]

That's unpossible. Ubuntu is the only lunix, and so it works flawlessly.

Re:Distribution problem

[Martin Soto]

Yes, the whole system.

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?

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

[Anonymous Coward]

Yes, don't use Ubuntu. Vote with your feet.

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

[Jeremy Visser]

Not that I blame you for not noticing, but have you seen /usr/share/alsa/alsa.conf? Find these lines:

files [
    "/usr/share/alsa/pulse.conf"
    "/usr/share/alsa/bluetooth.conf"
    "/etc/asound.conf"
    "~/.asoundrc"
]

Comment out the first with a #. Thus...

files [
#   "/usr/share/alsa/pulse.conf"
    "/usr/share/alsa/bluetooth.conf"
    "/etc/asound.conf"
    "~/.asoundrc"
]

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

[Clarious]

Uninstall PulseAudio = uninstall entire frigging GNOME desktop. I kept trying to tell it "no, I just want ALSA playback" in sound settings.

No, it won't uninstall whole GNOME desktop, that is just meta package for ubuntu-desktop, so you can uninstall it without any problem.
  Well, not really, if you install any audio apps that have pulseaudio output (like MPD) you will have to reinstall it again. In that case try changing alsa setting, pulseaudio takes alsa output by default, you can change that by set alsa output device to hw device (you will lose the ability to have multi programs to output at the same time that way). Or the better way is to fix /etc/asound.conf and make a dmix device (google for more information). Good luck!

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

[WWWWolf]

Thanks, I've got to try that when I'm at that machine next. Fortunately, the machine in question sits a few hundred kilometers away from me. It gives me a chance to rest.

As I recall it, I tried poking at the usual suspects in /etc/init.d, I did something to gconf, and I found some blog post that assured me there was some way to kill pulseaudio without uninstalling it and there were instructions on how to do that. But those were lies or misinformation. All lies. All misinformation. ...I hope this isn't though. Thank you. Configuring stuff would be easier if it all of it really sat in /etc.

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

[xtracto]

Uninstall PulseAudio = uninstall entire frigging GNOME desktop. I kept trying to tell it "no, I just want ALSA playback" in sound settings.

No, it won't uninstall whole GNOME desktop, that is just meta package for ubuntu-desktop, so you can uninstall it without any problem.

  Well, not really, if you install any audio apps that have pulseaudio output (like MPD) you will have to reinstall it again. In that case try changing alsa setting, pulseaudio takes alsa output by default, you can change that by set alsa output device to hw device (you will lose the ability to have multi programs to output at the same time that way). Or the better way is to fix /etc/asound.conf and make a dmix device (google for more information). Good luck!

Howdy shit... and you expect this to be the year of Linux on the desktop??

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

[pionzypher]

This help?

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

[Clarious]

No, sure, I think we will have to wait for at least another 5 years until the year of Linux on desktop ;)

But for me, it already happened, 2008 was the year of Linux on desktop for me. Hope you will have better luck with Linux in the future.

BTW, for your machine spec, I think you better use Lubuntu (Ubuntu - GNOME + LXDE), it is much lighter than Ubuntu.

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

[mikelieman]

I think that's a very important point. Up above in an prior comment, one of the devs was talking about the bad distro packaging.

BUT... What pulseaudio needs is a VERY CLEARLY LABELLED Off Switch.

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

[Anonymous Coward]

...any better ideas?

Go out. Have a couple of beers. Then switch to tequila.

My advice for all computer-related problems. The ones you remember the next morning are worth solving. The others ... Well, you'll have forgotten about them.

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

[Anonymous Coward]

1) sudo chmod a-x /usr/bin/pulseaudio
2) sudo apt-get install libsdl1.2debian-alsa (or libsdl1.2debian-all)
3) change all apps to use alsa and/or sdl
4) profit!

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

[Vairon]

I can recommend this as well. On an openSUSE system with broken pulseaudio, I ended up just moving /usr/bin/pulseaudio to /usr/bin/pulseaudio-broken

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

[gbarules2999]

The description of ubuntu-desktop says that it can be removed without issues. I don't know why everyone gets their undies in a bundle over that.

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

[phision]

--nodeps :)
try supplying the option of your package manager to ignore the dependancies and everything shall be fixed.

As for the article - I also got rid of pulseaudio, although it kinda worked for me. I just wanted to be sure, that no re-sampling/mixing/sw volume adjustment took place. All this processing distorts the stream, and the quality you get is lower than with the old "single-app-blocks-sound-card" OSS. When I play a movie or music I do NOT want any other sounds mixed in.
The only use-case when I need mixing is when I play some music as a background and I want to hear my IM notifications. So, it will be best if I can switch easily (automatically?) between the two modes. Pulseaudio does not have this ability, that's why it is gone. I may try OSSv4 though...

P.S. To windows fans - in windows it is even harder to guarantee undistorted output - the directsound driver will resample and mix everything.

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

[AdamWill]

"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."

Nope, not plain and simple. As I noted in other comments, this is due to resampling (it wouldn't happen if the audio in question didn't need to be resampled). The default resampling algorithm is chosen to give good quality on the vast majority of hardware (this is a polite way of saying you could pick a better system out of any given city dumpster :>). If you're running on extremely slow hardware, you can change the default resampling method with a fairly simple configuration file edit:

http://proaudio.tuxfamily.org/wiki/index.php?title=PulseAudio#PulseAudio

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

[bersl2]

Heh, I've got the inverse problem: I use Slackware and I've had to insert PulseAudio manually for quite some time, although with the upgrade to Slack 13 I just said "Fuck it" and installed GNOME SlackBuild, which has a build of a recent-enough version. Works well enough if you give it high priority and/or real-time capabilities. I've had to patch the source myself to make the damn thing understand file capabilities so that it could obtain that without suid root, PAM, PolicyKit, or dirty hacks using sudo. I'm trying to figure out whether the GSB's installation of PolicyKit will help me this time.

I feel that PulseAudio is too GNOME-centric. The example GUI tools he provides tend to require the latest and greatest version of GTK+2, which inevitably meant that I would end up having to build newer versions of everything down to glib2. I'd love to have something curses-based like alsamixer. (In fact, after adding to the preceding paragraph, I think there are more requirements on GNOME from many pieces of desktop software than there should be.)

The audio server itself taxes the ALSA drivers very much. I've had problems with my card that uses the cs46xx ALSA driver where the DSP (I think) on the card gets stuck and I lose the recording device or have a stuck playback that only goes away after a reboot (and only a cold boot will fix the recording device problem when it happens).

Though I should probably mention the caveat that the machine is overclocked (hey, it saved me hundreds of dollars).

I'm not sure how to reduce the requirement on PulseAudio for the other desktops. Maybe the pulse libraries should be dynamically loaded by every program that needs to do so. Configuring PulseAudio sure is less arcane than the black magic that is (used to be?) configuring ALSA.

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

[Veroxii]

I disabled pulse (not uninstalled it) last night following this guide: http://idyllictux.wordpress.com/2009/04/21/ubuntu-904-jaunty-keeping-the-beast-pulseaudio-at-bay/

So far so good - fixed up my Skype lag issues.

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...

Re:Or not...

[cheekyboy]

bug not fixed = bug ignored.

who gives a flying F about the red tape, if a developer wont see an actual problem and fix it, hes too stupid.

See a problem? then fix it, regardless of a bug list, report # id.

Dont wait and rely on youre submitter to do the red tape, they might be dead, so its up to you.

Re:Or not...

[Wonko the Sane]

who gives a flying F about the red tape, if a developer wont see an actual problem and fix it, hes too stupid.

See a problem? then fix it, regardless of a bug list, report # id.

The other side of that argument is that bug reporters outnumber developers. Not to mention the developers are frequently not getting paid by the bug reporters.

Developers should spend as much of their time as possible fixing bugs and adding features, not fixing poorly written bug reports. If the users want their bugs fixed they should either pay someone to fix them or help out the developers by writing good bug reports.

Re:Or not...

[mabinogi]

it's highly unlikely they developer was sitting around staring at his navel waiting for the bugs to be re-filed.

He would have been getting on fixing the bugs reported by people that don't waste his time.

Re:Or not...

[koiransuklaa]

See a problem? then fix it, regardless of a bug list, report # id.

And how do I mark it fixed? Oh, I can't because there is not bug report for this particular issue.

How does QA know to test the fix? They have no way of doing that.

How does the fix end up in release notes? It doesn't.

How do people with a similar issue find out if their problem is that same or not? They don't because the discussion includes 8 different bugs and is totally incomprehensible.

My point: You don't seem to understand what issue trackers are used for and how (calling it red tape makes you sound pretty ignorant). They are actually tools that are supposed to make our jobs easier. Filing bad bug reports may be good for you therapeutically but it doesn't make our jobs any easier.

Re:Or not...

[shutdown -p now]

If the users want their bugs fixed they should either pay someone to fix them or help out the developers by writing good bug reports.

Or switch to something that works without having to write bug reports according to form X7Y-2Z and then waiting for several months to see the bug closed (and 10 more bugs found in the meantime).

Like, say, OSS4. Or even ALSA.

Re:Or not...

[shutdown -p now]

Let us put this in perspective.

Say, Microsoft gets a bug report which actually covers several distinct bugs. If it then gets closed as "NOTABUG: do a proper bug report, noob!", what do you think the reaction of an average Slashdotter would be?

Yes, users are "dumb" - which is to say, they don't have time to waste on learning how to do bug reports in a perfect way. The fact that this person even bothered to find the bug tracker, and submitted his issues there, rather than just ranting on Slashdot, is already something to be glad for - most users won't bother to do even that. It's not exactly hard for the devs to take that bug report and split it properly; it may be hard for the user, however.

Yes, this is the reality of software development, FOSS or not. Learn to deal with it.

Also, this comment to his bug report is spot-on.

Re:Or not...

[Anonymous Coward]

I'm pretty sure Lennart is a busy guy. You are basically saying he should spend his time doing issue handling instead of development. You said the users do not have the time to file proper bugs... that sort of implies Lennart does have the time to do that -- for all the bugs.

I know the proper way to handle this is to have a QA/triage team (not between the developer and the user, but in addition to them) who solve problems like this. The reality is that we work with the resources we have, and sometimes theu do not include QA.

You claimed that splitting a bug is hard for the user. It may be hard to know what bugs to file beforehand, and this is why Lennart gave fairly good instructions and did half the work for the reporter (listed possible dupes). Filing the remaining few is not hard -- the point isn't to get it right on the first try, the point is to add info if the developer asks for it.

You also said it would be trivial for the developers to file the bug. I can't speak for Lennart, but I've learned to not do that: Maybe the report is missing information so the reporter needs to comment anyway, maybe the bug tracker has some automatic notices that get sent to the reporter, maybe the developers interpretation of the report is somehow wrong, maybe the bug is already fixed or the developer can't reproduce... It's a case "responsibility": there is a person who is responsible for keeping the report up to date and correct and there is a person who is responsible for fixing the problem.

Yes, this is the reality of software development, FOSS or not. Learn to deal with it.

I don't understand. This is a pretty special feature of open source, isn't it? Nowhere else do users and developers get communicate so directly -- this is exactly why correct bugzilla protocol is crucial: 1-N communication may explode so that the "one" never gets to do any real work...

Re:Or not...

[shutdown -p now]

I know the proper way to handle this is to have a QA/triage team (not between the developer and the user, but in addition to them) who solve problems like this. The reality is that we work with the resources we have, and sometimes theu do not include QA.

I can definitely understand the "limited resources" argument, but if you go after it, it's not the same as saying that there is no problem. You're just saying that there are not enough resources to solve this particular problem.

You also said it would be trivial for the developers to file the bug. I can't speak for Lennart, but I've learned to not do that

The normal way this is handled is by creating bugs for individual problems at granularity level most convenient for developers and QA, and then linking them up to user's original combined bug report.

Maybe the report is missing information so the reporter needs to comment anyway

If that's the case, you ask the reporter to provide missing information in the bug he originally reported.

maybe the developers interpretation of the report is somehow wrong

Not sure what this has to do with it. How that would not be a problem with a properly reported bug?

maybe the bug is already fixed

In this case, you close the separate bugs you've created that are already fixed as "duplicate".

the developer can't reproduce

In this case, you close the separate bugs you've created that don't repro as "not repro".

It's a case "responsibility": there is a person who is responsible for keeping the report up to date and correct and there is a person who is responsible for fixing the problem.

A user can only report to the best of his ability, which is quite often not on par with info that developers need, anyway. The only thing that you really need from the user are description of the problem, and, ideally, clear repro steps (if they are not clear, you keep asking questions until they become clear).

Yes, this all is properly solved by having dedicated QA staff (volunteers would also work, but it's probably not as interesting as coding, which is why you don't see many people volunteering).

I don't understand. This is a pretty special feature of open source, isn't it?

Not at all. Plenty of closed-source projects have bug trackers where developers communicate with users who report bugs directly. Heck, Microsoft has one!

Re:Or not...

[HRbnjR]

For the record, I (who started this thread) am the commenter you cite as "spot-on", I just added more info about my problems in the comments, I didn't file the bug :)

Re:Or not...

[AdamWill]

"Or switch to something that works without having to write bug reports according to form X7Y-2Z and then waiting for several months to see the bug closed (and 10 more bugs found in the meantime)."

Um. The OP filed a bug report covering five entirely separate problems, and multiple commenters then followed up talking about *other* different issues.

You will not find any bug tracker for any project anywhere in the world which would accept that as a useful way to try and track bugs. When do we set the bug to FIXED? When the first issue's fixed? The second? The third? The fourth? All five? How do we track what information is needed from who for what issue?

Lennart politely replied that several of the issues were duplicates of other reports, pointing out which. He asked for the remaining valid issues to be filed as separate reports so they could be properly tracked. Suggesting this is akin to "having to write bug reports according to form X7Y-2Z" is just ludicrous.

"Like, say, OSS4. Or even ALSA."

ALSA's bug tracker is essentially ignored these days, as they do not have the development manpower to track it.

Re:Or not...

[AdamWill]

"Say, Microsoft gets a bug report which actually covers several distinct bugs. If it then gets closed as "NOTABUG: do a proper bug report, noob!""

Microsoft? Bug report?

Where do I go to file bug reports with Microsoft? Last time I checked, the only option available was a black hole. You fill in your issue, and you get a page that says 'thank you for submitting your issue'.

Was it filed as a valid bug? Was it filed as NOTABUG: do a proper bug report, noob!? Was it set on fire and thrown into a lake? I don't have a freaking clue, because Microsoft's bug tracking system is not public, so I have no way to tell what the hell they did with it. I think that is just a tiny little mite worse than the case where you get a prompt reply from the _actual developer of the component you're complaining about_ explaining politely exactly how to file your issue properly.

Re:Or not...

[shutdown -p now]

You will not find any bug tracker for any project anywhere in the world which would accept that as a useful way to try and track bugs.

All proprietary software I've worked (and still working) on has bug trackers, and if I ignored such a bug report because it's not "useful way to track bugs", or, worse yet, specifically replied so to the user in the bug tracker, my manager would screw my head off - and rightly so. Once the developers and/or QA get a report of problems, it's up to them to split/reformat it in whatever way it is convenient for them to handle it. Ignoring it outright because it's "not done properly" is the worst thing you can do, because it effectively means ignoring actual bugs to prove a point.

When do we set the bug to FIXED? When the first issue's fixed? The second? The third? The fourth? All five? How do we track what information is needed from who for what issue?

You split it into several separate bugs in your tracker, and link them all to the original report by the user. You mark those separate bugs as resolved/dupe/no-repro/wont-fix as needed, and use them for any further internal communication between developers, QA, and whoever else is involved.

You mark the original bug as closed (not resolved) when you close all linked bugs for whatever reason.
If all linked bugs are dupes or not repro, then you close the original bug report as dupe or not repro.
If you close all linked bugs as resolved or dupes of resolved, then you also close the original report as resolved; otherwise, you explain to the user what was resolved, what didn't repro, etc.

Lennart politely replied that several of the issues were duplicates of other reports, pointing out which. He asked for the remaining valid issues to be filed as separate reports so they could be properly tracked. Suggesting this is akin to "having to write bug reports according to form X7Y-2Z" is just ludicrous.

Like it or not, at the point you tell the user that he didn't "report it properly" when a real bug was involved and his report actually contained all relevant info, no matter how badly presented - he will most likely leave and never come back. To your bug tracker if you're lucky, and to your product if you're not.

You can get away with more stringent requirements when the target audience is strictly developers, since they tend to understand these things, having been on the other side of it. But the bug in question isn't one such.

Re:Or not...

[shutdown -p now]

Where do I go to file bug reports with Microsoft? Last time I checked, the only option available was a black hole. You fill in your issue, and you get a page that says 'thank you for submitting your issue'.

It depends on the products. I don't know how it's handled for Windows or Office, for example. For some products (most notably, all developer-related products - WinSDK, Visual Studio, .NET, SQL Server, PowerShell etc), there are bug trackers at Microsoft Connect. Here are some examples of bugs that I have reported via it - as you can see, sometimes there's a fairly long delay before there is any response, and the answer isn't always "we'll fix it", but in all cases there is some response: 1 2 3 4 5.

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:Way not to get the point: why users are angry

[Draek]

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.

Then keep the complains to yourself, and don't waste developers' time with your pointless bitching until you're at *least* able to determine that you're bitching at the right developer.

Acrobat Reader may suck big donkey balls, but if I went to complain to Microsoft about it that'd only be a waste of time for them *and* me.

realtime

[Anonymous Coward]

the *true* way-to-go is to use a real-time kernel... that's the only way which will free us of those irritating hick-ups in the sound pipeline. perhaps even audiophiles will be able to use it then.

Re:realtime

[alukin]

It worked well with usual kernels for years before PA come into each distro.

Pulseaudio works for me better than ALSA or jack

[Anonymous Coward]

I use linux computers to play games (HoN, Savage 2), listen to music, talk via skype, watch videos using Kaffeine/VLC, watch youtube videos, etc. I also have a usb headset that I need to work in conjunction with my built in cards on both my laptop and desktop. Therefore I need an audio stack that can handle all that at the same time. When I used to use ALSA, it was a pain in the neck to configure everything to run, and even then some applications just would not behave when I tried to launch more than one sound output at the same time. I haven't tried OSS 4, but the OSS that comes with ubuntu is unusable for multiple applications and hard to use with multiple sound cards. For some time, I solved this by using jack server, but it has to be configured manually, and is apparently designed for music production rather than playback so I constantly had problems with it. Pulseaudio has been great. At first it was a little buggy and shaky, but with the newest versions that come with Karmic Alphas (now Betas) are stable and great quality. The only bug that has been bothering me is that my usb headset's microphone does not work with my laptop's intel sound card microphone, but since my laptop's microphone is good quality, it doesn't really affect me that much. It seems to be a common problem since a long time ago, but I don't think anyone has been able to report it efficiently. Anyway, I like pulseaudio for what it allows me to do. Obviously it's a young software project so there are going to be bugs and inefficiencies, but if everyone would support the idea and start fixing bugs instead of sitting there and complaining about it not being a "good idea", then perhaps we would have a very good sound system in linux that everyone could use.

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.

Re:The Vista Defense!

[Estragib]

FTFA:

It's not my intention to shift the blame around though. PA [PulseAudio] and the other layers of our stack should not be viewed as independent parts. If PA uses a new or previously unused feature of the drivers then we need to fix the drivers at the same time.

Re:The Vista Defense!

[chrb]

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!

Not quite. He actually wrote:

It's not my intention to shift the blame around though. PA and the other layers of our stack should not be viewed as independent parts. If PA uses a new or previously unused feature of the drivers then we need to fix the drivers at the same time.

Re:The Vista Defense!

[AdamWill]

right, because obviously it's completely pointless to identify where the problem lies before trying to fix it. Lennart's definitely saying 'the bug is in the kernel so let's not fix it', that's absolutely his position. It would make far more sense for us to say 'I don't CARE if the bug's in the kernel, go fix it in PulseAudio!' That would be a great way to write sensible and reliable software.

Or, wait, we could accurately identify when the bugs are in the kernel and then _fix them in the freaking kernel_, just like Lennart and Jaroslav (Red Hat's kernel audio developer) are doing. That would just be crazy, though. It'd never work.

Re:The Vista Defense!

[segedunum]

(Most) Audio drivers on Windows actually got fixed to make their change work, and don't be fooled - there's still a lot that's handled in the kernel. It's now standardised. What happened was that soundcards have got a lot simpler (and cheaper) to the point where drivers were replicating code to do the same simple things. Microsoft removed this and implemented sound processing that was previously in hardware or in several drivers between the kernel and userspace. They did that to reduce complexity and because they could do nothing with existing drivers. Unfortunately, that now means that many popular soundcards from several years ago simply don't and will not work with Vista or 7. Since Linux has soundcard driver source code available they don't need to take this approach to 'fix the mess'.

However and whatever, Microsoft found a way to not fuck sound up again by doing that and it doesn't mean that it's the correct approach for Linux.

4Front's interpretation IS relevant

[Anonymous Coward]

"The 4Front interpretation of GPLv2 is irrelevant" not when they have enough money to take you to court and you don't have enough to live AND defend yourself at the same time.

And GPL2 doesn't protect against patents. Neither does BSD or CDDL.

Now if the BSD folks donated code under GPL3 that is BSD licensed this would help BOTH parties:

1) BSD gets a test to see if the extreme openness of the license extends to software that is patented (making it as free as it was before patents on software)
2) GPL gets code that they don't have to defend

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

works great here, but...

[neaorin]

PA works just great on my machine, but make sure you have a recent version - anything before 0.9.15 had quite a few annoying bugs.

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

[Cyberax]

"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 same goes for pretty much anything else, Bluetooth included if you actually care."

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

"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.

"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.

Re:floating point works fine in my kernel

[Vanders]

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

So would an attempt to perform an integer divide by zero. That's why we call those types of problems "kernel bugs", and we are very careful not to create them.

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]

Avoiding divide by zero is easy.

But it will be VERY hard to avoid floating point exceptions in complex audio mixing code.

For example, graphics folks had to improvise by using fixed-point arithmetic which is translated to floating point at the very last moment (without using floating point instructions at all).

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

[Runaway1956]

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.

Seriously - try it, you'll 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.

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

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]

Hang up and drive? Get a cellphone with USB? I don't know - that's your problem. Bluetooth has no place in my house.

What does your 386 have to do with the discussion? You're just feeling argumentative, and you feel the need to put down OSS4 - which works?

Re:floating point works fine in my kernel

[zoloto]

I've never seen people anywhere other than slashdot try to do some of the things I've seen here. Bluetooth headset for your computer audio that you also use for your mobile phone? Seriously? That's the LAST thing I want to listen to my music on let alone let it drain battery life from...

Re:floating point works fine in my kernel

[Cyberax]

I use it for speaking. I just hate holding the phone for tens of minutes at a time.

Re:floating point works fine in my kernel

[Cyberax]

"Bluetooth has no place in my house."

Ok. But it has a place in my house.

"What does your 386 have to do with the discussion?"
It works, doesn't it?

"You're just feeling argumentative, and you feel the need to put down OSS4 - which works?
OSS4 is flawed, it has a design from the previous millennium. That's why.

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.

Re:floating point works fine in my kernel

[PeterBrett]

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

So USB (a wired communications standard) seems to do everything that Bluetooth (a wireless communications standard) claims to do?

Miss the point much?

Re:floating point works fine in my kernel

[Runaway1956]

The "point" is, we seem to have two solutions to the same problem. USB is relatively cheap and reliable, Bluetooth is relatively expensive. Why would I buy a bluetooth headset, when USB works so well? Why do I have to solve the same problem multiple times? I'm fairly sure that my USB headset is of superior quality to some bluetooth - or at least, I've not SEEN any bluetooth that is as large and comfortable as my USB, or delivers the quality of sound.

In short, if the problem is solved, why bother looking for another solution?

Re:floating point works fine in my kernel

[vadim_t]

Because bluetooth is wireless and USB isn't.

I have a bluetooth headset because with it I can go to the kitchen to get a drink, and still hear the music/voip/etc.

Using speakers would mean letting the people in the nearby flats hear it, and using a wired headset means a much more limited distance, and ocassionally nearly ripping the soundcard out of the computer when the cable turns out to be too short.

Re:floating point works fine in my kernel

[PopeRatzo]

If you care about sound, you don't use Bluetooth to carry audio.

Re:floating point works fine in my kernel

[QuoteMstr]

Plenty of people find Bluetooth Audio acceptable. Do you propose denying them this satisfactory output channel because you personally don't see the need for something so déclassé in a sound system?

Re:floating point works fine in my kernel

[PopeRatzo]

Everyone who knows me knows not to expect me to stay on the phone for more than about 1.5 minutes.

I don't think I've been on the phone more than 10 minutes since I was a sophomore in high school and had my first girlfriend.

I tried using a bluetooth headset for my phone once, not because I wanted to be able to talk hands-free but because I wanted to look like a total dork. I didn't like it.

If I wanted to wear a headset, I'd work for a phone bank, but then I'd have to kill myself. I went to grad school and got a PhD because I didn't want to work in a phone bank. So why would I want to wear the accouterments thereof?

Re:floating point works fine in my kernel

[PopeRatzo]

"Bluetooth has no place in my house."

Ok. But it has a place in my house.

C'mon, admit it, you just like wearing the little thing with the blue LED next to your ear.

Wearing bluetooth headsets is COSplay for techies.

Re:floating point works fine in my kernel

[HAKdragon]

Bluetooth audio isn't just used for headsets. For example, there are bluetooth headphones. I've never used them, but I'm aware that they exist.

Re:floating point works fine in my kernel

[statusbar]

People who believe that floating point has no place in the kernel are living in the dark ages.

The reality now is that thousands of products are shipped and in use now that process audio in real time on linux, in kernel mode, with major DSP style processing done with FPU and Altivec and SSE2 with userspace only involved to tweak coefficients.

If you ever saw a Cirque Du Soleil show, or went to disneyland, saw a metallica concert, or heard the opening ceremonies in Bejing, you have listened to audio being processed in linux kernel mode in floating point with both single fpu and vector procesing.

It would be nice to do it all in userspace.

Until the linux kernel is able to schedule real time user tasks with less than 10 microseconds of latency for a recurring interrupt every 166 microseconds, solution providers are forced to use kernel mode audio processing.

It is so unfortunate that linux audio is in such a mess with also, pulseaudio, oss. Developers should take a look at apple's CoreAudio for ideas if they can't figure things out.

--jeffk++

Re:floating point works fine in my kernel

[Cyberax]

Of course, FP in kernel exists and is used. Hell, I have seen even kernel modules in Fortran (!!!). But that doesn't make it right.

Latency of about 10 microseconds might actually be possible with the -rt kernel: http://www.densan.co.jp/pdf/realtime-en.pdf

Re:floating point works fine in my kernel

[statusbar]

Define 'right' ?

FP in kernel is the only way linux can be deployed in these scenarios.

the -rt kernel is not sufficient.

Xenomai is a lot better, however it does add for me up to 25 microseconds of latency on intel 2 ghz xeon.

So this means that in order to take dsp processing out of the kernel with the required audio latency we lose 15% of the cpu's processing power which is potentially 1.2 gigaflops with sse3!

so what is 'more right'? wasting 15% of your cpu due to scheduling latency even with xenomai or enabling fpu/sse in kernel?

--jeffk++

Re:floating point works fine in my kernel

[Anonymous Coward]

There are OSes out there which are not Linux which perform FP math in the kernel (including audio mixing) without any problems.

Re:floating point works fine in my kernel

[AdamWill]

"If I wanted to wear a headset, I'd work for a phone bank, but then I'd have to kill myself. I went to grad school and got a PhD because I didn't want to work in a phone bank. So why would I want to wear the accouterments thereof?"

You seem to be labouring under the misconception that anyone gives a flying shit what _you_ do. Use Bluetooth, don't use Bluetooth, we don't care. The point is that many people _do_ use Bluetooth, and "I don't use it so I don't have to care" is not a valid argument why their needs should not be taken account of.

Re:floating point works fine in my kernel

[eihab]

I've never seen people anywhere other than slashdot try to do some of the things I've seen here. Bluetooth headset for your computer audio that you also use for your mobile phone? Seriously? That's the LAST thing I want to listen to my music on let alone let it drain battery life from...

Not if you're like me and own a Motorola S805 Bluetooth DJ Headphones.

It has a crappy Mic and can probably handle phone calls to an "ok" extent (it has stereo audio and phone controls). However, I don't use it with my cellphone, I have a separate simpler (one ear) Bluetooth headset for that.

After going wireless it's _very_ hard to return to a wired set. I don't do anything professional with these, just music/youtube/etc., so the sound quality fits me just fine. It works with Ubuntu (my laptop) and Windows 7 (my workstation), although I have to admit that the Ubuntu experience leaves a lot to be desired (i.e. buggy-ness, writing a shell script and modifying .asoundrc do not come off as very user friendly).

So to sum it up, for someone like me a better Linux/PA/Bluetooth experience would be great. I've actually wanted to dig into the code and see how I can improve things, but I've never done that kind of programming before nor have I had the time lately to learn/do it.

P.S.: Final plug for the headset, sound is great if you're not an audiophile, battery life is amazing, and it charges over mini-USB, just like my cell phone and other headset.

Re:floating point works fine in my kernel

[segedunum]

Software mixing is trivial to do in the kernel, and I know it was certainly looked at in the move to 2.6 for OSS -> ALSA compatibility. Your post touches none of the reasons why the kernel general avoids FPU, so it's generally meaningles twaddle that shouldn't be responded to. Rest assured that it is a matter of principal and not a technical matter. Linus Torvalds has even said in the past that FPU can be done if there are instances where it is useful, which is why -fno-fpu still isn't used as far as I'm aware.

The notion this cannot be done is total bullshit.

Re:floating point works fine in my kernel

[segedunum]

So? My old 80386 does work too.

Yay. Let's pick out and reference a random, meaningless scenario where there might not be a math co-processor. Bull. Somehow I doubt you're going to get smooth audio on there with Pulse's insane low latency CPU requirements.

I tried it and don't like it.

Good for you.

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

Yay. Let's pick out a random, obscure use case for Pulse and pretend that no other problems exist!

The majority would like our basic laptop/soundcard/speakers set up to work properly and reliably first on existing hardware with software mixing done as a matter of course that will actually make the kernel OSS -> ALSA interfaces work finally, and the pre-requisite for doing anything else is that this set up doesn't get more broken than it already is.

Re:floating point works fine in my kernel

[AdamWill]

"So to sum it up, for someone like me a better Linux/PA/Bluetooth experience would be great. I've actually wanted to dig into the code and see how I can improve things, but I've never done that kind of programming before nor have I had the time lately to learn/do it."

With a coming-gen distro (Ubuntu 9.10, Fedora 12, Mandriva 2010) any Bluetooth headset you pair with should simply show up in PA as an output device like any other. Nothing else required.

Re:floating point works fine in my kernel

[Anonymous Coward]

"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?

Now at this juncture, the intrepid Runaway1956 faces a tough decision. He's made a simple enough claim, but the fearsome cyberax has felled it with one counterexample. Will he respond as a gentleman, admitting his claim was o'erbroad, and reducing it to "USB does everything bt does that I care about.", or will he play the part of his name, and run away from this impending conflict?

Hang up and drive? Get a cellphone with USB? I don't know - that's your problem. Bluetooth has no place in my house.

No, he goes one lower, and plays the part of a douche-bag, responding with the bizarre assertion that his failed claim is cyberax's problem -- apparently willing that anything not doable with USB should remain forever undone. Unfortunately for him, he's not Steve Jobs, and his feeble RDF attempt succeeds only makes him look epically lame.

A suggestion, Runaway1956: next time, try throwing chairs. You'll still look as lame, but maybe the physical exercise will do you good...

Re:floating point works fine in my kernel

[segedunum]

-msoft-float that should be. Seriously, software mixing is a trivial algorithm and there's no reason why you shouldn't be able to open /dev/dsp or something and simply pipe several outputs to it. It fits into the kernel philosophy of providing time-shared access to limited hardware and eliminates userspace complexity.

Re:floating point works fine in my kernel

[AdamWill]

"Seriously, software mixing is a trivial algorithm and there's no reason why you shouldn't be able to open /dev/dsp or something and simply pipe several outputs to it." ...and what happens when they're at different sampling rates?

Wow, clearly you've really thought carefully about this problem. I'm impressed.

Re:floating point works fine in my kernel

[Cyberax]

No, I really hate them. I have a real headset with mic and stereo headphones.

Re:floating point works fine in my kernel

[Cyberax]

OK. Mixing in the kernel is right for special purposes when you care only about squeezing extra 15% of performance sacrificing security, isolation and sanity.

Re:floating point works fine in my kernel

[statusbar]

The option really is to not use linux at all, which would be more un-sane!

--jeffk++

Re:floating point works fine in my kernel

[PopeRatzo]

"I don't use it so I don't have to care" is not a valid argument

It is the only valid argument.

Re:floating point works fine in my kernel

[AdamWill]

Nice selective quoting. What was the point of that? You make me look like I say something I didn't say, shorn of all context, and make...no useful point whatsoever.

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 ;-)

Re:I have a shorter guide

[LS]

I know you are joking, but I actually use PulseAudio's features. The PulseAudio Volume Control app is awesome. I have USB headphones as well as normal speakers. I can route sound for any application to either the headphones or the speakers on the fly, and mute at the application level as well. There is no way to do this easily without PulseAudio.

Ellis

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

[Entrope]

The people who care about audio latency generally aren't running on batteries (when did the whole world turn into unplugged laptops?). They didn't have to care about backwards compatibility because they used the only API that had ever existed on Linux (OSS). Most people don't need more than one app playing sound at a time; 80% of the time, I have zero apps playing sound, and 99% of the rest I only have one app that wants to play sound at a time.

Judging from your other comments, audio servers are a costly solution in search of a problem -- which was the direction I was originally going.

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

[Buelldozer]

Except it's not just Ubuntu. As an example the post one down from yours is complaining about a bare metal Fedora 10 install.

If the default configurations are so difficult to manage that two of the largest distributions going can't get them right then we, as a community, need to back up and rethink what we're doing.

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.

Re:Ubuntu is ruining Pulseaudio's reputation

[AdamWill]

If you care about audio latency you should be running a suitable sound server (yes, sound server). Namely, JACK. There are several custom distros available for audio creation purposes which come with a decent JACK setup and collection of appropriate applications out of the box. Running one of those would appear to be the sensible option.

Typical use of general-purpose Linux distributions, however, does not involve serious audio creation (the main use case which actually cares about latency). Hence it doesn't make much sense to prioritize latency over reliability or power usage in a general-purpose Linux distribution's default configuration.

Re:Ubuntu is ruining Pulseaudio's reputation

[Per Wigren]

There are many different problems with the Linux audio stack. The stack includes the Linux kernel, the in-kernel ALSA drivers and subsystem, the ALSA userland and PulseAudio.

PulseAudio has its share of bugs and missing/incomplete features and so has the other parts of the stack.

In Ubuntu, a lot of the problems are caused by its kernel configuration, mainly its too low resolution timer and disabled preemption. This cause PA to get much higher latencies than it should get and it has to use much more CPU time to keep the timing 100%. It can also cause sound to stutter when the CPU load is 100%.

Then there are other bugs in PulseAudio and the rest of the stack. These will of course affect all distributions, including Fedora 10.

The community is working hard to fix these bugs. If you look at each PulseAudio release, the changelog is massive. If you look at ALSA's driver changelogs you will notice that they have begun to get pretty massive as well. This means that tons of bugs that have been there for a long long time are now getting fixed because PulseAudio requires bugs to be fixed at the source instead of trying to work around everything. Yes, this is a good thing in the long run.

Re:Ubuntu is ruining Pulseaudio's reputation

[Anonymous Coward]

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.

Oh dear FSM, you didn't have to remind me about that mess. The times I've tried those and fled back to OSS sanity...

Sound support should be handled in kernel land (and stay there). Load the module, and away you go.

Re:Ubuntu is ruining Pulseaudio's reputation

[blackpaw]

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.

Yeah, it works - kinda hard to get skype work with anything else on Ubuntu karmic. But the sound skips and crackles something chronic and the mic levels had to be turned up to 240% before my voice was audible (yes I have disabled skype auto gain adjuster).

It worked a lot *better* on kubuntu which doesn't use pulse.

Re:Ubuntu is ruining Pulseaudio's reputation

[Anonymous Coward]

Really? Well shit, damn you Ubuntu for making my Fedora install unstable!

Re:Ubuntu is ruining Pulseaudio's reputation

[AdamWill]

Use Skype 2.1 (with native Pulse support), not Skype 2.0 (with patented Crack-Addled(TM) audio implenetation).

Re:Ubuntu is ruining Pulseaudio's reputation

[blackpaw]

Use Skype 2.1 (with native Pulse support), not Skype 2.0 (with patented Crack-Addled(TM) audio implenetation).

It was using Skype 2.1.0.47 from the Medibuntu Karmic repos.

Re:Ubuntu is ruining Pulseaudio's reputation

[Anonymous Coward]

It's not just Ubuntu. I've yet to see any Linux distro that manages to get Pulseaudio working well.

Re:Ubuntu is ruining Pulseaudio's reputation

[evilviper]

All of them had worse backwards compatibility than PulseAudio.

Not true. Just about every audio app out there supports esound, not because it was first, but precisely because it's so similar to standard auto output.

And if you get an app that doesn't have ESD support, you use the esd wrapper, then it does...

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.

Not so much. SBLive! cards have been supported forever, and it didn't take long until the lowest-end sound chips included hardware mixing.

Re:Ubuntu is ruining Pulseaudio's reputation

[evilviper]

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.

That's not a nit pick... That's reading comprehension failure.

You'll notice he was speaking in past-tense... Before hardware mixing was generally available, and well before ALSA was even around (and we were all MUCH HAPPIER before ALSA...).

Re:Ubuntu is ruining Pulseaudio's reputation

[AdamWill]

Doesn't read that way to me.

Hardware mixing is actually *less* common now than it used to be, since there's less need for it (because Windows does software mixing).

Or yes

[HRbnjR]

Oh give me a break, what a crock!

First off, the whole damn thing was so FUBAR, reports from users surely aren't even needed at all! The slightest bit of rudimentary testing reveals obvious breakage in multiple serious ways! You are getting hung up on all the details nice users like me took the time to write in there, when in reality we should have all just reported "all of us think this thing sucks for totally obvious reasons, have you even tried it? Fix your broken shit.".

"I will ignore all other issues mentioned in comments here."

Second of all, if I want to communicate with the developer by submitting bug reports written on a fricken paper aeroplane, then that's my prerogative - 1 report, 10 reports, initial bug, in the comments, it doesn't matter. The bottom line is that users are communicating serious problems to the developer, and the developer is *ignoring* them, because he doesn't care for how they were submitted. And, yeah, sure, that's his prerogative too, but it doesn't change the fact that the software sucks, problems are being brought to his attention, and he's not acting on them.

Third, you can't expect users to file separate reports for separate issues if they aren't capable of discerning how many issues there are! I already spent an hour identifying and writing down all the problematic and erratic behaviour I was seeing - and I have no idea how many different bugs that actually is. He should be thankful for receiving carefully specified reports at all, and use his knowledge of the system to immediately identify how many bugs there are, and go file separate bug reports himself, rather than expecting me to somehow slog through figuring it all out. He's not being paid to write software for me, but I'm also not being paid to do QA for him.

Re:Or yes

[Entrope]

As a developer, I agree with you on everything except the paper airplanes. At work, I tell people to file different bug reports when they combine things, but that's part of what they get paid to do. For my open source work, I'm happy to get problem reports -- and in general, the more detailed, the better -- and if I think a bug report should be split, I'll split it as many ways as makes sense to me.

(Or, more briefly, mod parent up!)

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:Or yes

[Anonymous Coward]

You can bitch as much as you like, but you forget you are not paying for their time and you're entitled to nothing. Get over yourself. If you had any skills you'd submit patches yourself.

Re:Or yes

[Anonymous Coward]

I've read your comments on bugzilla. You were a whiney little arsehole having a rant. 3 of your 5 problems were addressed reasonably well and you were asked to raise seperate issues for 2. You then threw your dolly out the pram.

Re:Or yes

[shutdown -p now]

This is a "problem" with the open source community as whole

It's not a "problem". It's a problem, without the quotes.

Making users report bugs at all is hard as it is. If you try to force them into doing it in a "properly organized" way, to save yourself a little bit of effort, then they won't bother to do it at all after seeing a reply to their disorganized, but good faith bug report saying "These issues will be ignored until you file them properly".

Re:Or yes

[Wonko the Sane]

Making users report bugs at all is hard as it is.

True

If you try to force them into doing it in a "properly organized" way, to save yourself a little bit of effort,

The exact magnitude of that "little bit" is the key. I'm not a developer but I can see that if the number of users numbers in the thousands (millions) and the number of developers numbers in the dozens that a large bottleneck exists. For a scaling perspective it makes sense for as much of the task that can be distributed and parallized (assiging a bug report to the correct component) to be done by the users.

Personally when I ask for free support I try to be as little of a burden on the developer as possible. Of course if I am paying for a certain level of support then a different set of expectations apply.

PulseAudio is overhyped

[jonaskoelker]

I don't care whether problems are caused by the kernel, a driver, an application, the phase of the moon, or whatever.

My sentiments exactly: http://linux.slashdot.org/comments.pl?sid=1409057&cid=29791305

Perhaps PulseAudio is just getting most of the "blame" because it is the most recently changed part of the audio subsystem

It could also be that in a lot of users' eyes, PA is overhyped. Some distros get PA installed and configured right, others don't (yes, I'm looking at you, Ubuntu). From the perspective of the users of the distros that don't get PA right, Pöttering is saying "PulseAudio is the greatness" which conflicts with their experiences. Telling someone that a thing they dislike is good for them and they should want it is not a great way to make friends (see also "eat your vegetables").

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.

Re:A legend in its own mind

[dissy]

Tell me again about PA's awesomeness.

But it IS awesome! Once configured correctly, it will do your dishes and give great head! (Still no sound though)

Re:A legend in its own mind

[BitwiseX]

WARNING: incoming car analogy.
So I buy a Nissan, which has a Rockford Fosgate stereo. Nissan wires it incorrectly, and I get no audio. I install a Kenwood. Everything works.

Using the methodology you applied above, the reponse is: Fuck Rockford Fosgate. The answer actually, is Fuck Nissan for hooking it up wrong.

A product is as good as is it's implementation. Lots of people seem to be pointing fingers at PA for EVERY problem they have with audio. SOME (but not all) of the issues should be owned by the various distros, for not following the directions given by PA because "our way is better"

Re:A legend in its own mind

[mr exploiter]

So what it could be a million things from the linux core to the fedora maintainers to your laptops manufacters. You could also installed windows and I'm sure you'd have sound working. Linux awesomeness. Just pick up a debugger and find out the bug or sharap.

Re:A legend in its own mind

[Anonymous Coward]

The same happed with my OpenSuse 11.1 install.

So it turns out that Volkwagon can't install those stereos either. Nor could whatever the car-equivalent of Ubuntu is.

Maybe those stereo making people need to start thinking about industrial design.

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

[Anonymous Coward]

Get off my lawn! Kidsh theshe daysh do not know how to code, back in my day everything wash jusht one and zero. Get a job hippie!

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

[jmv]

10 years ago, you couldn't play two sounds at the same time unless your card could handle it in hardware. 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. ALSA was *generally* a good idea, but with a bad implementation. It's better than OSS, but still suffers from some of the same problems, like the fact that the range of many hardware parameters is decided by the card (but at least the sampling rate was OK) and makes it near impossible to write code that works with all cards. As far as I'm concerned, *all* the sound servers on Linux (can't speak for other OSs) prior to PulseAudio were complete garbage. PulseAudio may have issues, but it's the first one to at least do its job.

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

[Anonymous Coward]

And.. I should get off your lawn.. right?

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

[QuoteMstr]

the range of many hardware parameters is decided by the card

How would it work otherwise?

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

[Wonko the Sane]

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

I've only been using it since yesterday and I can only speak for myself but I don't have any major problems. On the other hand I use Gentoo so my threshold between "minor annoyance" and "major problem" might be skewed a little bit. One minor annoyance I've run into is that in order to make Wine play nicely with PulseAudio on a 64 bit system I need to build a 32 bit PulseAudio libraries in a chroot so that the third-party winepulse patch will compile.

But other than that everything's good...

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

[jmv]

I meant "playback/capture parameters". For example, if you want low delay audio, you need to set the period size and the number of periods, but there's no set of values that are guaranteed to work. A good API should be transparent and work the same way for any 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.

bad user tools for pulseaudio

[GNUPublicLicense]

We need C only coded user tools to interact with pulseaudio, with THE 3 basic levels:command line,ncurses and GTK (has in the MPD audio player). Pulseaudio is important for upmixing/downmixing, setting volume per application (or attached an app volume to a global fixed gain volume). I dare remind people that ALSA top priority is 0 latency to hardware. alsalib plugins are already too much.

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.

Pass the Buck!

[Anonymous Coward]

It's not just for Windows anymore!

My take on PA

[amn108]

PulseAudio has been working like a dream on my Thinkpad T43/Ubuntu 9.04, and I really appreciate its more modern level of audio control than the outdated inflexible "volume up/down" interface with which most of us have been living for 10 years already. In my opinion the features PulseAudio provides as a sound server outweigh most of its problems. Bashing it because it is unstable is not fair IMO. It is not like they slack off, they actually are working on it. Ok, so maybe PulseAudio IMPLEMENTATION is maligned, but the features are certainly welcome. After getting used to per-application volume controls and on-the-fly stream redirection, I dont really welcome going back to the stone ages of audio interfaces.

Common attitude

[MoeDrippins]

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

    I go through this at my company. We have a cadre of theoretical purists who code they way [they think] they SHOULD be coding, and the way it SHOULD work. In the end, what SHOULD be and how other things SHOULD be using or working with your stuff doesn't mean $#@!. What matters is it works. PA doesn't.

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

[Anonymous Coward]

Amen Brother!

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

[Anonymous Coward]

You have somewhat of a point but it's mired in bullshit.

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.

It's interesting you claim that, as most of the god awful code I've seen seems to come from self-trainees. I also laugh at your jab at C++, since you talk about bloat I can only assume that you are asserting that the devs should be using the holy C89 language which only proves you know jackshit since C++ is no higher from the hardware than C and can even be smaller and faster (by making it easier to eliminate duplication) under some circumstances. Remote Procedure Call is another 'WTF?' claim — you know Unix is very big on these things called Pipes, right? What the hell do you think those are? The tech may be being used wrongly (using a hammer to nail in a screw) but a blanket assertion of uselessness is horsecrap.

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.

Wow, the dev shouldn't care about the end user, huh? The end user should be happy with a 50 page menu and a screen full of unlabelled buttons, any of which could crash their system? Nice to know that you don't actually work in the industry since you'd be unemployable with that attitude.
News flash genius, software exists for the purpose of providing an interface between the user and the hardware, to enable the user to command the hardware to do something useful for them. I think you need to reevaluate your world view since you seem to be a mile off the ground.

That said, PulseAudio is just the latest version of ALSA and ESD, it sucks just as hard because the morons who keep coming up with this crap don't realise that you have to simplify the system as you add new layers, not expose even more bullshit complexity on top of the existing bullshit complexity, hell, it doesn't even eliminate the necessity of competing framework things like JACK [Now what? PulseAudio + JACK on ALSA with OpenAL with ...]. (Phonon is a good example of doing it right by simplifying the crap that is Xine and Gstreamer instead of making it yet more complicated [different area though]).

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

[Anonymous Coward]

Unbelievably, after that entire post full of insults and put-downs, you haven't even made a single technical point.

Sometimes I wish we could go back to the slashdot 10 years ago where we actually had meaningful technical discussions, rather than pointless subjective rants.

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

[Lemming Mark]

Not entirely fair to take GNOME and Compiz as examples as Linux software - they're cross-platform AFAIK so they probably run on BSD too. And they're very much high level applications code, some of which is either rather large or rather new. What are you using as examples of BSD code? The kernel? The BSD libc and userspace utilities? You'd always hope that core OS code is better written than application-level code, so if they're higher quality it's not entirely surprising, more reassuring.

If you compare the equivalent components in GNU/Linux and BSD then that would be interesting and a bit more fair IMO. Many people seem to think BSD still wins in that quality comparison but it would be interesting to see whether this is so much the case these days....

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

[Anonymous Coward]

It sure as hell isn't a natural response to consider the attackers' perspective and think maybe they have a point.

Very true. However when you try (tens of thousands of times) to point out politely where problems are, with detailed debugging steps, and at times even code patches, with evidence of how many less broken apps act broken after the changes are applied, and all tens of thousands of posts are viciously attacked by the developer, then clearly it is time for another tactic.

While the forms of complaint the GP made will not do anything to change the mind of the original developer, the desire is to make the people *above* that developer realize how much of the community is disliking how the developer is handling it, to have them removed from their position.

You can't complain about using a 'last ditch effort' complaint after all other options have been exhausted, and that has definitely been the case here.

He can claim what he is doing is 'right' and 'correct' all he wants, but when 90% of the user base is begging and pleading for 'broken' and 'wrong' in your point of view, perhaps you should deliver 'broken' and 'wrong' in the same way it is being asked for...

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

[godrik]

+10^6

I am almost quitting Linux to BSD because of their non-sense API. Gnome is the worst pile of crap I have ever seen. It override every single configuration you can do. (e.g., no keyboard setting linked to the tty, gnome does it all)

Network-manager is RIDICULOUS. Where is the ifconfig front-end to configure the wifi they use in some BSDs ?

PA is yet another software crap to do sound. Shitty latency, shitty API, shitty configuration, shitty driver. Whys the HELL are people packing that ?

I am really waiting for when they will remember the unix philosophy. one problem, one tool. one tool, one problem. KISS. and write a clear man page.

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

[bonch]

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.

The advantage of commercial software is that they listen to customer feedback or else they lose sales. The sign of a professional attitude is not treating your software like a pet project that's above criticism.

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

[Blakey Rat]

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.

If you're trolling, that's brilliant.

If not, then... WTF! Even ESR, the craziest of the crazy, has written articles about how much open source usability sucks shit. Like this article: http://catb.org/esr/writings/cups-horror.html

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

[petrus4]

Unbelievably, after that entire post full of insults and put-downs, you haven't even made a single technical point.

Sorry, I forgot those this time. I've gone through them plenty of times before, though.

In the case of GNOME:- Horrible bloat and complexity pretty much everywhere, a dep list as long as your arm, replication of the single worst design blunder made in Windows, (GConf, a clone of the Windows Registry) the fact that gdm is an opaque monstrosity that is impossible to configure, XML-RPC, making everything as non-configurable as possible, and for the things that are configurable, insisting that only GConf should be used, rather than dotfiles.

Then there's the simple fact that the whole thing is butt ugly, as well.

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

[koiransuklaa]

I'm going to agree with the AC: your post is a failure. The build-up is massive and then you finish without a single real point.

I'll take GNOME as an example: your point seemed to be that GNOME is an example of poor code quality, horrible design and uncooperative developers, with BSDs as a reference point. After reading your comment I don't know which BSD Desktop Environment I should look at to see comparable code that is higher quality (something that apparently should leave GNOME so far behind it isn't even funny). I have no idea how GNOME is an abomination (don't get me wrong, I know GNOME has problems, but you imply a lot more). I don't know any of the numerous occassions where the GNOME developers were told about this.

Please explain, preferably in a way that justifies all the trash talk.

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

[AdamWill]

"Very true. However when you try (tens of thousands of times) to point out politely where problems are, with detailed debugging steps, and at times even code patches, with evidence of how many less broken apps act broken after the changes are applied, and all tens of thousands of posts are viciously attacked by the developer, then clearly it is time for another tactic."

I notice the above paragraph appears to be missing approximately 10,000 references.

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

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

[Yunzil]

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

Perhaps you should consider a different career. If you're not coding for the end user, you're just masturbating.

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

[petrus4]

Perhaps you should consider a different career. If you're not coding for the end user, you're just masturbating.

Ordinarily I wouldn't bother dignifying this with a response; but it's worth pointing out that unfortunately, the above thinking seems to have infected the majority of programmers, at least where Linux is concerned.

It might take a while, but I'm predicting that gradually the Linux community are going to figure out the truth about this; that eventually, in their mad and largely inexplicable frenzy to recruit the most mindlessly unintelligent, illiterate, and technophobic of Windows users, Linux itself will be ruined to the point where eventually someone will stop one day and ask themselves, what the real benefit is of Linux continuing to exist at all.

Windows has only improved in the last few years because Microsoft started making real technical integrity more of a priority; stability and security, rather than continuing with insane feature creep. Linux is going backwards, because it is doing exactly the opposite.

The other thing that's worth commenting on about the above quoted statement, now that I think about it, was the level of arrogance inherent in it. I've mentioned this before, but it's the type of statement made by people who believe that writing programs to be as complex (rather than as simple) as possible, is the "modern, sophisticated," approach, and that the entire earlier UNIX philosophy is simply an irrelevant, obsolete anachronism.

You're wet behind the ears.

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

[Nivex]

Ya know, you had me... right up until "the end user, need to die." In the end it is ALL about the user, without whom all you have is SkyNet, or the MCP. Do you want to write code for your machine overlord, or for a fellow human being?

Ultimately that end user wants his/her computer to _just work_, which would happen if the tenets you laid out in your diatribe were followed. I find it strange that you would contradict yourself so vehemently right at the very end.

I think I know what you're actually trying to say here, but it would be foolhardy for me to infer that you contradicted yourself _again_ by being an elitist (self-righteous) BOFH who is better than the "end user".

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

[petrus4]

I notice the above paragraph appears to be missing approximately 10,000 references.

This type of cheap, pseudo-empirical trolling does nothing other than demonstrate just what an imbecile the person engaging in it really is.

I blame Wikipedia for the rise of this tactic; demanding citations from someone when you've already made up your mind on an entirely subjective basis, that you're going to disagree with them no matter what; in that case, the request for cited sources is essentially one of two things.

a) A form of rhetorical sarcasm, because you believe the other person won't actually be able to cite sources at all.
b) A request for further ammunition which can be used to discredit and/or humiliate the other person.

I am learning to truly hate atheism. Don't try and troll me with the idea that I'm making a false assumption about you being an atheist, either. The above tactic is straight out of their rhetorical playbook.

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

[Yunzil]

Windows has only improved in the last few years because Microsoft started making real technical integrity more of a priority; stability and security

Coding for stability and security is coding for the end user.

but it's the type of statement made by people who believe that writing programs to be as complex (rather than as simple) as possible, is the "modern, sophisticated," approach,

On the contrary, it's the type of statement made by people why actually want their software to be used. By actual people.

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

[Anonymous Coward]

You can try to defend it; you can justify it however you want, but any way you slice it, GNOME is a train wreck. The entire project should be scrapped and rewritten from the ground up, but it won't be, because it allows Mark Shuttleworth to delude himself that he can offer a functional equivalent of Windows.

But he does! It's got a registry, goes slow, is non-configurable, and attempts to take over the universe by annoying the users it's allegedly "helping"! If that doesn't make it functionally equivalent to Windows, what would?

FWIW, I used to be a GNOME fan; back in the 1.x days, it was quicker across the board than K, looked nicer, and was WM-independent by design. About 2.4, though, I'd begun to notice it kept getting bigger, less configurable, and kept ditching quite decent components to roll their own. After Metacity showed up, with no evident way to switch window managers (it was still permitted, but exposing wm selection in the control panel was now "too much choice"), I took a long hard look at it, and decided I'd had enough, and while I didn't switch my familiar primary desktop over just then, I resolved that no new versions need apply. This was only a couple months before Pat dropped it from slackware, which was indeed welcome news...

Never installed GNOME since, and since I bear a long-standing grudge against KDE (due to unreasonable slowness way back when, which I hear has been fixed, and a moronic dependence on its own wm, which hasn't been), ditched the "real" desktop environments for good.

Since then, I've run barenaked window managers (saw(fish|mill), fvwm2, wmii, and awesome, mainly) with a random assortment of lightweight apps, and recently have started running e17 on my laptop, which is the most "end-user desktop" of any of my ~10 boxes. Every time I use someone else's ubuntubox I'm reminded how glad I am to have switched -- theirs feel like Windows Vista (came with my laptop, have used it for a while due to hardware support), but look like trash; mine run like the devil and, with e17, actually look shinier and feel more responsive than Vista although the CPU's downclocked to half-speed.

GNOME should die in a fire, and while I'm mindful of the benefits of having some distro more newb-friendly than slackware about, Ubuntu can die in the same fire -- something less repugnant will take its place. But that's the funny thing with software. If I hand someone a bowl of dogshit and tell them it's chocolate ice cream, they'll throw it in my face. But if I hand them a CD of dogshit, they'll install it and they'll tell me it's ice cream.

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.

Re:Could you get sound from multiple sources?

[Anonymous Coward]

Why do I need sound from multiple sources simultaneously? Never saw the need, myself.

Re:Could you get sound from multiple sources?

[Idaho]

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).

Actually, yes, I could get sound from multiple sources - at least at some point and not without a serious amount of pain.

I used to have a Terratec card that supported hardware mixing, and this was sorta-kinda-mostly-supported by unstable/development/self-compiled versions of ALSA (which for inexplicable reasons stayed in development/unstable/etc. pretty much forever), and in that case you could simply open /dev/dsp multiple times and sounds would play simultaneously. Since the mixing is done by the hardware, no sound daemon was involved.

But yeah, you want a uniform API even if not all cards can do that (for some unfathomable reason that probably involves it costing more than $0.05 to implement). Why we still don't appear to have such a stable interface today is exactly the question I'm asking. PulseAudio may or may not be to blame, but whether or not this is the case is completely besides the point.

The point should be: why hasn't this problem been adressed in Linux, in 2009, whereas all other major OS's solved this problem at least 10 years ago?

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.

I couldn't agree more.

Re:Could you get sound from multiple sources?

[jelle]

"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."

And that's fine for me, when I'm playing a video, the email program or battery monitor doesn't have to bling at me.

And that's fine for me, because with pulseaudio I often can't get sound from less than one thing (no sound at all untill I killall pulseaudio). Now that's annoying.

Re:Could you get sound from multiple sources?

[Tetsujin]

Why do I need sound from multiple sources simultaneously? Never saw the need, myself.

One of the most important use cases is when something just happens to have already established its own access to audio output, and you may not be aware of this (for instance, you've got a browser up and flash is running, or the desktop is running a sound server which has /dev/dsp open) - and you want to play a movie or a game or something, and have it not just spew out a bunch of errors and then fail to play audio...

Re:Could you get sound from multiple sources?

[Tetsujin]

But yeah, you want a uniform API even if not all cards can do that (for some unfathomable reason that probably involves it costing more than $0.05 to implement). Why we still don't appear to have such a stable interface today is exactly the question I'm asking. PulseAudio may or may not be to blame, but whether or not this is the case is completely besides the point.

The point should be: why hasn't this problem been adressed in Linux, in 2009, whereas all other major OS's solved this problem at least 10 years ago?

Don't be silly... People have addressed the problem of coming up with a stable, uniform API for sound... In fact, multiple, independent software teams have addressed the problem and come up with various competing solutions... But that's become a problem in itself, of course. :)

Re:Could you get sound from multiple sources?

[amRadioHed]

Frankly it's not fine for most people. I like being notified of an instant message while I'm listening to an MP3 or TV.

Re:Could you get sound from multiple sources?

[BikeHelmet]

Alsa fizzes for my soundcard. Other mixers don't. Other operating systems don't.

Re:Could you get sound from multiple sources?

[Yfrwlf]

What are these "standards" and warm fuzzies you speak of, why would anyone want to play nicely with others, and why are you still on my lawn?!!!!!

(in other words, I agree) :P

Re:Could you get sound from multiple sources?

[r00t]

I never tried to do such a horrible thing.

I didn't have the problem of lame software holding the audio device until GNOME insisted on starting a stinking sound server. Yep, it's that sound server itself that caused the issue in the first place.

The proper kernel fix is to allow multiple opens of the device. The most recent opener is heard, while the others get /dev/null until the recent opener is done. Yeah you could mix, but that just sucks. (it degrades the sound, it adds latency, and I don't want to hear such a cacophony anyway)

Re:Could you get sound from multiple sources?

[Anonymous Coward]

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

So, no annoying BOIINNNNG in the middle of the music, just because a spam mail ended up in my mailbox.

Please, can I get real life upgraded to have the same feature? No annoying phone calls when I'm listening to music, no Jehovas Witnesses ringing my doorbell, and no neighbours telling me to turn the music down. Please?

I never understood why people would want one program to start playing annoying sounds in the middle of the sound of another program. I know windows does it. Sounds terrible. Listening to music, and then suddenly a Flash add starts blabbering in the background. Really annoying.

I had the problem for a while on my Linux box too. Until I found out that Alsa had changed to enable dmix by default. Once I turned it off, the problem went away. Oh yeah, and the lag disappeared too.

Re:Could you get sound from multiple sources?

[Anonymous Coward]

Random observation: FreeBSD still uses OSS. They've had software mixing (and thus virtual channels and multiple sound sources and all that goodness) for, ooh, at least ten years?

Re:Could you get sound from multiple sources?

[AdamWill]

That's a different version of OSS. Linux kernel only ever had what's generally referred to as OSS/Free, which never had software mixing capabilities.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Pulse Audio is a nightmare.

[Zombie Ryushu]

Pulse Audio is killing Audio on Linux. It breaks everything. Its compatible with almost nothing. Even if you disable it, its not really gone, because everything processed through ALSA gets processed through PA using extra CPU cycles. Its horrible, and my distributor won't get rid of it in spite of repeated calls for Pulse Audio's death.

As for the mixer issue. If a given sound card does not support hardware mixing, it should be up to the ALSA Driver to handle that. If a given sound card does not support hardware midi, it should be up to ALSA to see to it Timidity handles that. I'd give anything to be able to remove Pulse from the big name Linux distros. We need one Audio driver frame work: ALSA. We need one game abstraction layer. SDL.

No more Pulse Audio, no more JACK, no more Port Audio. None of that bullshit.

Re:Pulse Audio is a nightmare.

[AvitarX]

Have you used JACK?

I really think it offers something not available otherwise.

Re:Pulse Audio is a nightmare.

[AdamWill]

"We need one Audio driver frame work: ALSA. We need one game abstraction layer. SDL."

Good thing PA isn't an audio driver framework or a game abstraction layer then, really, isn't it?

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.

what to do...

[ninjanissan]

apt-get remove pulseaudio

At last!

[digitig]

he believes the majority of issues are being triggered by misbehaving drivers or applications

Linux is finally learning from Microsoft!

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.

How ironic...

[Anonymous Coward]

Its funny that this is music related, but that Meatloaf's most recent commits to the Linux source tree have been in the form of his new scheduler, which has nothing to do with sound at all! Anyone know when his new scheduler will be showing up in public distros?

Re:How ironic...

[WillDraven]

You just sent me off on a few minutes of frantic googling trying to figure out if the singer was a kernel hacker in his spare time. I mean, he looks sort of like a slashdotter...

Re:Article is doomed to failure, but PulseAudio is

[Engeekneer]

Now taking the time to explain it this well and in length, would deserve the mod points I don't have. You'll have to do with a thank you post.

Am i reading this correctly?

[nimbius]

so, because a chip manufacturer and a phone company decided to add pulse support, that means everyone is using it? how about Mackey, or Elation? companies that provide light and sound solutions for major venues?

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Your first sentence makes what point what exactly?

As for the ACL stuff, are you suggesting that all audio apps are rewritten to handle the ACLs and know about all the other applications that are out there so they can take appropriate action when particular events occur? Policy should not be something that has to be coded into every app, it should be centrally managed.

As for "application controlled latency is good" comment, sometimes you don't get that luxury. If you start off your stream playing on your laptops built in speakers and then have your bluetooth headset take over (it's a VoIP call so I want to use BT here), then the latency will *change*. The application cannot tell the bluetooth protocol to "be quicker". The application has to react to the latency information provided by the sound system.

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.

And with PA, "sending data from one userspace process to another" can be done with a zero-copy approach (the whole core of PA is zero-copy and lock free).

Benevolent dictators

[mnemonic_]

It's only accepted as long as infighting between developers continues to waste energy on all sides. A war of attrition that's characterized open source for so long that no one knows any better (1984, war is peace). A "benevolent dictator" should roundup the sound guys and stop their fucking around. Mark Shuttleworth shaped Ubuntu up to be the ONLY decent desktop linux distro, Guido van Rossum made Python a uniquely usable and efficient programming language (ditching backwards compatibility with the 3.0 release), and Steve Jobs carried Apple out of the gutter. So many open source projects flounder without strong (and sometimes arbitrary appearing) direction.

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....

Re:Benevolent dictators

[Anonymous Coward]

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

You do realize that Ubuntu is nothing more a marketing department releasing Debian ISOs, don't you?

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

"Thank yous" gratefully received, as is beer (tho' obviously it has to be Free Beer... the cornerstone of all FLOSS work!)

Re:Article is doomed to failure, but PulseAudio is

[LizardKing]

Fundamentally, PulseAudio is architecturally flawed, and I don't get the impression from reading the rest of the Slashdot comments that people are confusing the roles of a networked audio daemon and a lower level kernel API. The problem is that PA is userspace, trying to do things that require kernel level control of timing. This is made worse by ALSA on Linux, which has poor latency, poor design, appalling code and sketchy documentation. I don't say this based on anecdotal comments from others, but on my experience working with ALSA in order to abstract the differences between various Unix like systems. In the BSD world, PA has only been (grudgingly) accepted because so many things now depend on it - but it actually duplicates some of the functionality already offered by the native kernel API. And just because a few big names are using it doesn't magically make PA any good - I can think of a number of widely used technologies that are piss poor compared to alternatives, but have become entrenched for reasons other than technical excellence. As for switching users on a desktop machine, I don't know anyone who does this, nor can I think of any reason why doing so would absolutely require an over engineered audio daemon.

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:This is why we have Macs

[LizardKing]

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

I can't mod you up, as I've already posted, so I'll just aadd this note of agreement. The issue for me isn't just audio recording, for which Ardour is acceptable, but MIDI. Rosegarden was the only option for MIDI composition on Linux last time I checked (about a year ago), and it's incredibly unstable. Even Steinberg Pro 24 on an Atari ST was more stable. I ended up buying a second hand Mac and a license for Ableton Live instead.

Re:This is why we have Macs

[Xtravar]

I've heard really good things about Reaper under WINE. But even I use Windows for home recording. Windows XP 32-bit, that is, because audio software is more behind the times than critics can even claim of Linux.

Re:This is why we have Macs

[Tetsujin]

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

"...and then you have two problems." XD

Re:This is why we have Macs

[mcgrew]

Funny, I know a lot of professional musicians and they're all on Windows.

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

[Anonymous Coward]

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.

That may be the case for music listening, but for music making, 20 milliseconds is barely usable

Another Pulse anecdote

[jjustus]

I installed Ubuntu 9.04 on my new AMD64 laptop and tried to play some music. Aqualung (my preferred player) did not work properly with Pulse's ALSA emulation. For example, switching tracks caused a delay of several seconds. Next I tried to switch to Audacious, but it also behaved weirdly, and the sound quality was horrible. I also think I had problems with other applications. Next, I got rid of pulseaudio and suddenly everything worked 100%. Just reading this thread shows that this is not an uncommon experience. Conclusion: Pulseaudio is not ready to be installed by default on desktop systems.

Why getting it wrong sucks

[AceJohnny]

PulseAudio was adopted to solve the problem of broken audio for some users, but PulseAudio broke stuff for some users for whom things worked before.

There is more loud complaining about newly-broken systems than there is praise for newly-working systems (humans are a fussy lot), and the complaining is drowning the praise.

Lesson: when you change something, make sure it works well and more importantly doesn't break anything for existing users, or the backlash will be terrible. Apple knows this, Ubuntu is learning this.

Re:Why getting it wrong sucks

[Skapare]

You mean that MP3 won't play now?

Re:Why getting it wrong sucks

[Gunstick]

mine didn't work with oss

it did not with alsa

and still does not with pulse

Seems i'm always on the recieving side.

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.

Directsound is removed

[Anonymous Coward]

Oops.

Re:Article is doomed to failure, but PulseAudio is

[QuoteMstr]

PulseAudio is architecturally flawed

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

networked audio daemon and a lower level kernel API

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.

PA is userspace, trying to do things that require kernel level control of timing

You should read up on POSIX realtime scheduling. There's nothing PA does that required kernel-level support. In fact, you should be happy PA runs in userspace: the less code in the kernel, the less can go wrong in the kernel. Besides: being in the kernel means that you're non-portable, that you can't use floating-point, and that you have various other coding constraints. Userspace is far better.

As for switching users on a desktop machine, I don't know anyone who does this

Pauline Kael, on Nixon: "How can he have won? Nobody I know voted for him."

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

[pionzypher]

I hope all the Ubuntu users *snip* who formed their opinions of PA back then will give PA a second chance on a well integrated setup.

I'm sorry, but the problems aren't resolved. I've been running karmic for about three weeks now and have experienced the same issues with PA that I had with earlier releases of Ubuntu. For example: flash in a web page can basically disable audio on the box. lsof shows firefox as the culprit and killing ff, followed by a full restart of PA & Alsa will fix the issue temporarily. If I something else is actively using sound (audacious for example), the issue doesn't seem to manifest.

Removing pulse and using plain alsa/esd prevents the issue from occurring as well. This can be the fault of Ubuntu but the result is still the same: I have fewer issues if I remove PA.

I suppose my point is this. As a user, I don't care if the buffering is awesome. I don't care if the framework supports modern desktop features. I do care if my sound works without having to jump through hoops repeatedly. I don't hate PA, and will continue to try it out with new releases. But I will continue to remove it after having issues.

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

I guess the OP is talking about buffer size, when he says latency. Use a big buffer when you are showing video, so you don't have to wake up all the time to transfer stuff to soundcard.
I do wonder how a 20 sec buffer will behave if the user decides to shut the audiostream down, or transfer it to another soundcard. Does it take 20 seconds to do that?

For games you are using a small soundcard buffer at the expense power. If your game dosn't have to do internal mixing (e.g moving soundsources), you can use a big PA buffer, and let PA mix your sound (which then has to use a small soundcard buffer to get low latency).

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.)

I've never had a working Pulse installation

[aussersterne]

with Fedora, multiple versions, multiple different machines and sound hardware families. Sometimes I thought it was working, but then I would find some critical aspect of sound that didn't work or an upgrade would break it a day or two later and sound would disappear. Even those moments when it was partially working, sound was always out of sync and choppy and consumed heavy CPU resources.

I always de-install the damned thing, and then suddenly sound works perfectly. It's like an extra component that's insanely complex and designed especially to BREAK sound in Linux.

Where is the protocol?

[Skapare]

Programs (especially daemons and services) that communicate with other programs (especially over pipes, streams, and network connections) should have a protocol. The protocol should be designed and standardized (even if a one person effort) and the implementation designed around that (and around whatever else it is involved with). Many bugs I have seen in programs are ones where the program failed to correctly implement the protocol. But many more bugs I have seen in programs are ones where the program is also creating the protocol at the same time, and the protocol is whatever happens to come out of the program. You can tell when you have one of these bad boys when the author(s) say to "read the source" when asking about the protocol. So, where is the protocol ... documentation (it's not so much the answer, but how this gets answered, that provides the clues to many issues).

Pulseaudio a Proprietary software?

[Anonymous Coward]

Not really containing less bugs, not really fast, not really working well, not really simple, not really flexible,...
It's really like reading about OSS vs. Proprietary battle...or say s/Proprietary/Pulseaudio/ :)

Re:Article is doomed to failure, but PulseAudio is

[Tweenk]

Video playback with an audio lag of several seconds?

Latency != Audio desynchronization.

He specifically says that you need accurate timing information to compensate for audio latency, and display the video later so that it matches audio. Assuming that the latency is always less than 1ms and not compensating at all is NOT the way to get acceptable audio sync.

Re:Article is doomed to failure, but PulseAudio is

[Engeekneer]

Now if we could only implement a beer sharing protocol that works over internet...

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:PulseAudio is broken

[QuoteMstr]

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

Perhaps you could call attention to particular aspects of PulseAudio's design you disagree with? Perhaps propose a better implementation? All I see above is an elaborate (if unhelpful) bug report.

Re:PulseAudio is broken

[OverflowingBitBucket]

> Perhaps you could call attention to particular aspects of PulseAudio's design you disagree with? Perhaps propose a better implementation? All I see above is an elaborate (if unhelpful) bug report.

I have no interest in digging into audio API design at this point, and certainly have no intention to be led into it in a lengthy attempted defence of my experiences prompted by your quick three-sentence reply.

But in at least a partial answer to your question, I did mention the importance of getting the core functionality correct. If you actually interested in my thoughts on what could be improved, and not just trying to discredit my post, then my suggestion would be to focus on that. Getting the core functionality right.

Re:PulseAudio is broken

[QuoteMstr]

My point is that you have no business commenting on PulseAudio's design. You're not qualified, and you're not even interested in becoming qualified. You couldn't tell whether OpenAL or set BLASTER is the better API, and you're just throwing around big words in lashing out at being bitten by a bug. What you should be doing instead of foaming at the mouth here is filing real, helpful bug reports, helping track down problems, and generally trying to do something. Lambasting the PA developers for not "getting the core functionality right" when you couldn't even tell me what the hell the core functionality is is definitely not in the helpful range. How much did you pay for this crap again?

Re:PulseAudio is broken

[OverflowingBitBucket]

> My point is that you have no business commenting on PulseAudio's design. You're not qualified, and you're not even interested in becoming qualified. You couldn't tell whether OpenAL or set BLASTER is the better API, and you're just throwing around big words in lashing out at being bitten by a bug. What you should be doing instead of foaming at the mouth here is filing real, helpful bug reports, helping track down problems, and generally trying to do something. Lambasting the PA developers for not "getting the core functionality right" when you couldn't even tell me what the hell the core functionality is is definitely not in the helpful range. How much did you pay for this crap again?

This will be my last reply to you.

You do not have to be an expert on a particular area in order to point out glaring problems that an enormous number of people are having, much like you do not have to be a chef to point out that your dinner is terrible.

You have absolutely no idea of my experience in this area, and you are making some very poor assumptions.

And pulling out the whole "it's free, so take what you're given" thing is ludicrous, and coincidentally the precise point at which I stopped taking you seriously.

Re:PulseAudio is broken

[Gunstick]

what to improve:

* if legacy programs break sound output by grabbing /dev/dsp, well then remove the damn dsp device. I hate the /dev/dsp busy messages. That should no longer happen!
* tell distributions to deliver a full featured installation and not just the bare bones thing where the pulseaudio controls are set with alsa or oss interfaces.

Re:PulseAudio is broken

[AdamWill]

"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."

Where 'abject denial' is defined as documenting the issues and workarounds - https://fedoraproject.org/wiki/Bug_info_PulseAudio#Playback_problems.2C_crackling_or_skipping - and fixing them (most of the issues of this kind were fixed by kernel fixes in the last six months)? Wow, it's like a whole new vocabulary world out here.

Re:PulseAudio is broken

[plague3106]

Its interesting to hear from Linux users what they expect users to do. With this kind of mindset, is it really any wonder I went back to Windows?

Re:PulseAudio is broken

[Anonymous Coward]

You do not have to be an expert on a particular area in order to point out glaring problems that an enormous number of people are having, much like you do not have to be a chef to point out that your dinner is terrible.

Sure you can comment on "Distro X's transition to a PulseAudio-based sound stack sucks" if you like but you have absolutely no right to go commenting on the fundamental architecture and design of PA itself for all the reasons QuoteMstr listed.

Even your example above about being a chef is incorrect. Sure, you don't need to be a chef to say that dinner is terrible, but you at least need to take a vague interest in cooking to say that that the sauce needed more red wine, or that a twist of lime and a handful of mint was needed to bring out the flavours etc. etc.

In open source you have to give *constructive* criticism. You would be expected to discuss with the chef why you thought his meal wasn't up to par and he'd be expected to listen to you. If you just shout "You suck at cooking" through the kitchen door on your way out, they keep on walking to the M$ or Appl€ store.

Re:PulseAudio is broken

[OverflowingBitBucket]

> ... but you have absolutely no right to go commenting on the fundamental architecture and design of PA itself for all the reasons QuoteMstr listed.

I choose not to remain silent on issues that are being repeatedly denied and deflected, despite being widespread. Why on earth should I? Oh- and I have plenty of experience working on systems that have had to interact with hideously-bad systems before, and compensate for their deficiencies. I could go into them, but why? You wouldn't consider it "good enough" if I did, because they weren't *specifically* related to audio.

> In open source you have to ...

> ... they keep on walking to the M$ or Appl store.

One: Stop being so arrogant as to assume you can lay down the rules as to what someone must do, while trying to champion your cause by flying the "open source" banner. Two: Stop trying to associate a broken audio subsystem with "open source" and "Linux versus Microsoft/Apple" in order to bolster the argument and gather numbers. You want to chat about these topics some time? Fine. But let's not pretend that PulseAudio problems are about either of these.

You're trying to attack my credibility rather than my content, implying I have said or done things that I have not, suggesting I have no right to comment in the first place, and to top it all off fall back to emotional arguments by trying to associate things with established Slashdot darlings. Do you honestly not expect to be called on so many logical fallacies, on Slashdot of all places?

Are you sure you're not just the same guy, just posting anonymously this time?

I think I'll post this one sans Karma bonus.

Re:PulseAudio is broken

[petrus4]

My point is that you have no business commenting on PulseAudio's design. You're not qualified, and you're not even interested in becoming qualified.

He was wondering if you were trying to discredit him. Looks like you proved his point.

Here's what he's qualified to comment on. He's qualified to comment on the fact that his sound isn't working.

If Linux developers don't want users who aren't qualified to do more than that, then they need to stop making statements about how they want to take over the world, or how they want everyone who currently uses Windows, to use Linux instead.

Pulse's single main problem is rampant, uncontrolled featuritis. I got that from the linked article. You don't need to know anything about the minute crap involved with the design. There's too much emphasis on including a whole heap of features that most people don't care about or need, when the basic functionality of simply playing sound.

It is also true, as has been said elsewhere in this forum, that sound playback in FreeBSD just works; simply, quietly, without fuss.

You therefore have no excuses, no justification, and no escaping this issue. Pulse is a failure. It is not doing what its' users want it to do. End of story. Sounding as smug, elitist, and dismissive as you want is not going to change that fact.

Re:PulseAudio is broken

[AdamWill]

"He's qualified to comment on the fact that his sound isn't working."

Sure. It's called a bug report. Believe it or not, in the days before PulseAudio, sometimes people's sound didn't work either. Imagine that! Sometimes life sucks.

Extrapolating from 'my sound isn't working' to 'the entire architecture of PulseAudio, which I am about to make a wild-ass guess at describing, is utterly wrong' is what he's not qualified to do. Which is exactly what the post you're replying to said. What's hard to understand?

Re:PulseAudio is broken

[petrus4]

Extrapolating from 'my sound isn't working' to 'the entire architecture of PulseAudio, which I am about to make a wild-ass guess at describing, is utterly wrong' is what he's not qualified to do. Which is exactly what the post you're replying to said. What's hard to understand?

The point is that simply responding that he is unqualified, is both elitist and counterproductive. It is also entirely moronic, because as he rightly pointed out, if it can already be demonstrated at a macroscopic/external level that the application has failed, (i.e., that sound is not working) knowledge of the design on a more minute level is entirely unnecessary.

If the application is not performing its' stated task, to provide audio playback, then it is a bad design. It is that simple. He doesn't need to have read the source code to know that.

Re:PulseAudio is broken

[AdamWill]

"if the application is not performing its' stated task, to provide audio playback, then it is a bad design."

ah. So if I can find any system, anywhere in the world, on which audio playback does not work in FreeBSD, you will admit that FreeBSD is 'a bad design'?

wow, way to paint yourself into a corner, skippy.

Re:PulseAudio is broken

[mr exploiter]

HAHa you owned him hard.

Re:PulseAudio is broken

[OverflowingBitBucket]

> Where 'abject denial' is defined as documenting the issues and workarounds - https://fedoraproject.org/wiki/Bug_info_PulseAudio#Playback_problems.2C_crackling_or_skipping - and fixing them (most of the issues of this kind were fixed by kernel fixes in the last six months)? Wow, it's like a whole new vocabulary world out here.

You can choose to remain wilfully ignorant in order to make your point, or you can actually take into account the rest of the post you are replying to. I highlighted the general attitude around PulseAudio. Re-read the paragraph starting with "The order of the day...". I have seen examples of each of these things. Have you? If not, you can even find most of them in the article! Are you so tied up in PulseAudio advocacy that you really can't see these things happening?

Anyway, discussion has mostly moved on from here. My position on this whole thing is very clear. I'll drop a reply or two to another couple of posts you've made in this thread that caught my eye, and then I think I'll leave it at that.

Re:PulseAudio is broken

[OverflowingBitBucket]

> "if the application is not performing its' stated task, to provide audio playback, then it is a bad design."

> ah. So if I can find any system, anywhere in the world, on which audio playback does not work in FreeBSD, you will admit that FreeBSD is 'a bad design'?

> wow, way to paint yourself into a corner, skippy.

Strawman. Plus a thoroughly unjustified strike at petrus4, with the cherry being a thoroughly patronising attitude. Let me be the first to call you on all three of these things.

It is very clear that petrus4 was *not* saying the words you are trying to put in his mouth. It is clear that he is referring to the fact that since PulseAudio is having such widespread trouble performing its core functionality (playing sound) across so many systems, it is badly designed. And I completely agree with this position, personally. A well-designed system would not have so many problems.

Oh, and as for "bug reports" mentioned above, they're not a cure-all, nor an appropriate thing to suggest as a response when buggy and incomplete software is shoehorned into distributions. I'm also not going to waste my time putting together bug reports for PulseAudio specifically when the general attitude is as I stated in my original post- ie. everything-but-PulseAudio is to blame. Don't try to push the responsibility for a chain of poor decisions onto the people affected by them. I'll submit bug reports to the projects that I think will do something useful with them.

And to close- I will clarify that one reason I find the PulseAudio design so poor is that it simultaneously assumed and relied on all applications and drivers being perfect, such that it could be treated as a drop-in replacement. Which clearly didn't work- and really never had a chance to do so. I can't think of one half-competent person who would design a system with a vast culture of interacting applications with this assumption. By my words, I'm *not* saying or implying that the PulseAudio designers are incompetent, I am just baffled that they approached the design and integration of their system without taking this properly into account. I'm wondering what influences led to this decision. I'm guessing somebody with the know-how was pressured in some way for a deliverable. Anyway, PulseAudio integration leads to a gigantic regression in audio functionality in distributions. A properly-designed system would not cause this. Smash-it-all-and-let-people-pick-up-the-pieces isn't a solid design methodology. Oh, and let me be very clear. I am more than qualified to comment on this aspect of the design. So let's leave off any "not expert enough" arguments, okay?

Anyway, I'm done. What does such an argument achieve anyway? I'll save my positive contributions for the day when I see the PulseAudio developers and distribution integrators say: "Um, sorry guys, we sorta screwed up. What's the best way forward?"

Re:PulseAudio is broken

[Yfrwlf]

"Perhaps you could call attention to particular aspects of PulseAudio's design you disagree with?"

Its failurenesstitude? Or how about non-workingness version 1.2? Those were two pretty bad features IMO.

Sorry, it's just that as others have pointed out, it's pretty broken and not ready for prime time, and its inclusion in many popular distros by default was a poor decision and has contributed to Linux looking pretty second-rate. I hope the problems get resolved but perhaps that will take improving the old systems, starting something else, or replacing everything. Linux needs quality rock-solid low-latency playback first and features second, not to mention good standards which require as little as possible for application developers to interface with it.

Re:PulseAudio is broken

[OverflowingBitBucket]

> HAHa you owned him hard.

For sufficiently low values of "owned", I'm guessing.

Re:PulseAudio is broken

[AdamWill]

I really don't see how the context changes anything. The sentence I quoted is perfectly clear that "abject denial" refers to "Stutters and skips are the norm, audio systems that worked previously no longer do", and as I said this is absolutely not at all true.

Re:PulseAudio is broken

[AdamWill]

"Strawman. Plus a thoroughly unjustified strike at petrus4, with the cherry being a thoroughly patronising attitude. Let me be the first to call you on all three of these things."

Nope. Not guilty, on any of the above. Follow the thread of the conversation. It was not a discussion of general issues, it was a discussion of a specific post where a commenter extrapolated directly from 'my audio doesn't work' to 'PulseAudio is, overall, a terrible idea'. petrus4 was defending this. hence my post is entirely legitimate. If he was _not_ defending this, you'd have a point.

On the wider topic, actually, you're interestingly close to the mark. PulseAudio was intentionally, and by agreement between multiple distributions, introduced when we knew it still had functional regressions compared to the previous situation.

Interestingly, exactly the same thing happened with ALSA when it replaced OSS/Free. This has been explained before, but to rehash...

Why? Because we needed to pick something to fix the damn mess. At the point when this was done, every distribution was using plain ALSA, plus esd for GNOME and/or arts for KDE messing up the works (or, in some cases, distros trying to use esd on KDE...). It was fairly obvious that no-one cared about esd and arts was going to be dying too, though I believe at that point no-one knew what was going to replace it (turned out to be Phonon). There were _several_ potential replacement sound server candidates around. PulseAudio (previously PolypAudio) had been around for years; it was available on most distros, but virtually no-one ran it because going out and choosing to install a minor-league sound server is not on most people's daily lists of Really Good Ideas. It was painfully obvious that the current situation was nowhere near good enough in terms of handling things real people actually want to do with sound (for instance, enabling S/PDIF output on many cards was a gigantic pain; ditto analog surround output; ditto dealing with multiple sound devices; that's just the low-hanging fruit). It was equally painfully obvious that none of that was going to get fixed in ALSA (as I said earlier in the thread, people who will yell loudly that it all should be fixed in ALSA are ten-a-penny; people willing to actually write ALSA code, not so much).

The problem is that it's very hard to move forward from that situation without picking a solution. No alternative sound server was never going to get critical mass by relying on optional installations. As long as it was optional, no application or desktop was going to care about properly integrating it, it would be very difficult to get necessary fixes made in the kernel and so on. So the distributions together decided to pick PulseAudio and implement it as standard essentially just to make it very clear where the future was going and provide the necessary impetus for other work to get done.

If we hadn't done that, we'd probably _still_ be stuck on plain ALSA, looking more stupid with every passing year.

Was this for the best in this best of all possible worlds? Probably not, but it was the best available of a quite bad set of choices. Note that distributions implemented the change differently: Fedora did it first and has no 'off switch' because part of the point of Fedora is to drive ultimately beneficial change in desktop Linux at the cost of temporary issues (this is hardly unique to PulseAudio). Ubuntu did it a little later for safety. Mandriva went quite early but has an off switch in the draksound utility, as MDV tends to focus on working as well as possible at any given point in time.

Look at the bright side: a huge amount of work has been done since PA was 'promoted' to improve ALSA, improve desktops (it's hard to look at gnome-volume-control in Fedora 12 and *not* say it's a vast improvement on the pre-PA era) and improve application integration. We now actually have a more or less coherent sound story across all Linux distributions, which we _never_ had before. Everyone knows where they stand and where things are going, and we're getting a damn sight more productive work on audio done than was the case before. That's the reasoning behind how things were done.

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

[Sycraft-fu]

Ya high latency may be on in a pure playback, non-interactive environment. Like playing a DVD or something. Ok, I suppose a couple seconds of latency would be fine, so long as everything is sync'd. If the video and audio are delayed such as to sync, the delay can be pretty high. Fine, but that has nothing to do with computers, an interactive medium. Here, latency is a very bad thing. The reason is that you want things to be responsive to user actions. If a user does something, you want an immediate response.

As such you need to keep latency as low as practical. Where precisely human perception on this kind of thing lies is a bit up for debate but it is well established as in the 10s of milliseconds. Thus you want to be able to dispatch data FAST. If you are taking a tenth of a second, you are taking too long.

What's more, there's no reason this can't be done. We see it done all the time on Windows and OS-X. They have no problems with low latency audio. Even when used "normally" meaning using something like DirectSound talking through all the software processing, you are talking maybe 30ms of latency. This works pretty well and seems to do fine for consumer stuff. However if you need better, for recording or something, you can go far lower using kernel streaming, or using a separate pro API like ASIO. Sub millisecond latencies are possible, though you do need a fast system to avoid dropouts.

This is all without any mucking about either. It just works. To the extent you configure anything it is in pro software and that is just the length of the buffer. You don't need a special kernel or the like.

Computers are fast these days, thus latency should be low. When a person does something, they should get immediate response from their perspective. That is good practice in general, but a total necessity in things like games.

What gets me in particular about people being defensive about this (like the grand parent) is that, as I said, Windows and OS-X do this and have done it for a long time. People aren't asking for something that is new, they aren't saying "Man I wish some OS could get this right, could Linux be the first?" They are asking for something that has been done by other OSes well for a long time. Heck they aren't even asking for Windows 7/X 10.6 level, they are asking for Windows 2000 level.

It should not be such a hard thing to have an API, or set of APIs, that programs can use to talk sound to the OS, and a spec for drivers to interface with that audio layer. The audio layer should then be able to handle simple tasks like volume control and more than one sound playing at a time, and it should be able to do so with a reasonably low latency and no skipping.

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

[Saval]

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.

For many uses you can (and should) buffer few secs of audio and video, but there are definitely cases where it's not possible. One case for example is realtime audio effects. You get audio stream from audiocard input, do processing and send stuff to audiocard output. You just can't have latency of more than few ms between input and output. So no buffering

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...

Re:Article is doomed to failure, but PulseAudio is

[_merlin]

You're assuming content is available a long time before it needs to be played. This just isn't the case. I want my games to feel snappy; when I drag iTunes' EQ sliders, I want to hear the difference immediately; I want to hear my trading terminal beep as soon as a new instrument is listed on the exchange. Striving for the lowest possible latency is the easiest way to achieve this.

Actually, Poettering,

[yttrstein]

"says such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people."

Yes, actually they are.

Re:Actually, Poettering,

[jefu]

The usual response to this (and not just about "technical people") is something like :
Then they're not really technical people.
It's the "No true Scotsman" line of reasoning.

Re:Actually, Poettering,

[colin_s_guthrie]

Well I'm a true Scotsman, and a technical person and certainly agree with Lennart on this front. Don't know what that means overall :s

This is why I switched back to Windows

[occamboy]

I had Ubuntu running on our main home computer for more than a year. There were definitely some annoyances, but things were tolerable. Until I upgraded Ubuntu (I forget which version) and sound was broken hard - I spent hours fixing it, but got calls from home every few days asking me to "help fix the sound. it's broken again". Finally, I gave up and switched back to Windows.

Re:This is why I switched back to Windows

[petrus4]

Yep, and you try and tell people what your experience was, and you get downmodded Troll, because you're not saying what the adolescent developers want to hear.

Linux programmers need to understand that they're not going to have their cake and eat it too. Frankly, I don't know why they want to win the mainstream desktop so badly, but they keep talking about it.

Yet they are also myopic, and determined to remain oblivious to end-user complaints when things aren't working.

A little logic here; if you want to conquer the desktop, it makes sense to listen to the desires and concerns of said desktop's users.

Re:This is why I switched back to Windows

[TerranFury]

This is not a troll but rather solid advice. Do not give Linux, even the comparatively-easy Ubuntu, to novice computer users. The second they're asked to do a distro upgrade -- and this happens every few months -- they'll be calling you for help because, face it, a bunch of stuff will break (hundreds of posts in the Ubuntu forums stand testament to this fact). Whereas Windows will just silently and without causing problems install minor patches.

Maybe the answer is to use something stabler than Ubuntu which has a slower release cycle. Debian stable?

But if the choice is between XP and Ubuntu... I'm starting to think (and I did not originally) that it's easier to get XP secure enough than it is to make a Linux user-friendly and functional enough.

OSX may also be worth considering seriously.

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:GStreamer?

[EsbenMoseHansen]

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?

As I understand it, Pulseaudio acts as a backend to GStreamer to actually play sound. Right above the hardware layer. It is mostly a GNOME invention, with all that entails, and replaces ESD, which I understand worked just as well as the KDE3 arTs.. that is, not very well at all. If you use ALSA, it adds an additional layer underneath alsa, which probably explains the extra latency people complains about. From a user perspective, as far as I can see, it offers 2 things, of which one of them only apply to the Gnome applications.

• (Gnome only): Kills ESD
• Allows dynamically redirecting of sound input and output of running apps to and from sound cards

The 2nd point is of course entirely moot for those who only have 1 sound card.

Hope I didn't miss anything important!

Re:GStreamer?

[Wonko the Sane]

The 2nd point is of course entirely moot for those who only have 1 sound card.

This is a shrinking use case. Plenty of people already have hardware devices (besides sound cards) that handle audio data.

Re:GStreamer?

[EsbenMoseHansen]

The 2nd point is of course entirely moot for those who only have 1 sound card.

This is a shrinking use case. Plenty of people already have hardware devices (besides sound cards) that handle audio data.

I have 2 personally, but I do not know anyone else who does. So I think it is fairly important point for many people. I might be wrong, of course.

Re:GStreamer?

[AdamWill]

"Whatever happened to GStreamer?"

er, it's there and in active use by zillions of applications across multiple problems. but it lives at a higher level of the stack. gstreamer *outputs* to PulseAudio. (or, y'know, ALSA, if PA isn't there.) gstreamer wasn't designed to do the stuff PA does, that's not its job.

Re:GStreamer?

[Wonko the Sane]

I have 2 personally, but I do not know anyone else who does. So I think it is fairly important point for many people. I might be wrong, of course.

I'm going to come out and say that having a webcam is mainstream, since my grandmother has one (she's not on Linux).

One of those and/or some type of USB or Bluetooth headset for VOIP and you now need some method to connect applications to the correct inputs and outputs.

Re:GStreamer?

[AdamWill]

You missed quite a lot: http://en.wikipedia.org/wiki/PulseAudio#Features isn't a bad overview, right now. Colin or Lennart wrote a good 'why PulseAudio?' page, I think, but can't find it right now.

One major point is that saying "The 2nd point is of course entirely moot for those who only have 1 sound card" isn't _exactly_ accurate. 'Sound device' is a better phrase to use, because the modern world has moved on rather substantially from what you may be thinking of as 'sound cards'. Any Bluetooth audio device is a 'sound card'. Any USB headset is a 'sound card'. Any USB speaker is a 'sound card'. Many webcams are 'sound cards' (they have mics, these days). Any USB handset for pretending you're using a real phone when you use Skype or whatever is a 'sound card'. Any other computer running PulseAudio can be a 'sound card'. With the recent Rygel integration, any UPnP audio client can be a 'sound card'...

Re:GStreamer?

[EsbenMoseHansen]

Ok, I missed network transparency for sound, another rather esoteric use case. The rest is just rehash of what I said in several different ways. A lot of the "features" are just marketing, like "Low-latency operation".

And ok, I call all those sound cards, but if you want to call them devices, that is fine with me. Most people I know still only have 1.

Don't get me wrong. I think the ability to move streams around is interesting, but rather than introducing yet another layer, I'd like to see that at the ALSA layer.

Re:GStreamer?

[EsbenMoseHansen]

I have 2 personally, but I do not know anyone else who does. So I think it is fairly important point for many people. I might be wrong, of course.

I'm going to come out and say that having a webcam is mainstream, since my grandmother has one (she's not on Linux).

One of those and/or some type of USB or Bluetooth headset for VOIP and you now need some method to connect applications to the correct inputs and outputs.

USB headsets, sure for gamers --- after all, that is why I have one. In other countries were phone-over-IP via. the computer has caught on, it might be interesting for that group.

Does your grandmother use a webcam? I am impressed, despite the OS. I've only had one webcam, in a laptop, which used the same mic as the soundcard. I only ever used it once: for a mirror. A lousy mirror, too :)

My point is that pulseaudio got a poor reception among users because it solves a problem not many users have in an invasive and error-prone way.

Re:GStreamer?

[Wonko the Sane]

Does your grandmother use a webcam?

Yep. Facebook too...

Re:GStreamer?

[EsbenMoseHansen]

Does your grandmother use a webcam?

Yep. Facebook too...

Impressive, and delightful :) My grandmother is 96, she doesn't remember me anymore :/

Re:GStreamer?

[msuarezalvarez]

You seem to think that PA and GStreamer are competing or something. You clearly do not have any idea of what at least one of them is...

Then I suggest a new API and protocol

[Skapare]

I suggest what is needed is to start over and design a new API and a new protocol ... completely separate from any implementations. Then you can have multiple implementations of the API, as needed (at least one per OS that wants to use it).

The API should, of course, be user space (the library implementation then translating to the kernel calls it needs to do, and maybe with kernel call changes if the kernel cannot now deal with the new needs). As for OO, that's fine for binding into an OO language. But the API design should specify its interface in all major languages, whether OO or not (do not just design it for a couple low level languages and hope all the higher level languages implementations cross bind the API the same way). The C++ interface should specify the exact classes while the C interface should be a non-OO specification around an OO design. Again, all the specification needs to come from the one source, or inconsistent variations can happen and ruin it.

The network interface should also be clearly specified before implemented (though not ruling out implementing concurrently with feedback to the protocol design). And there needs to be a renewed discussion of what format (codec) the audio needs to be in for the journey over the network. Ultimately that needs to be something negotiated over the protocol (as well as other things like sample rate, channels, resolution, etc).

And the network method should be designed to work over at least TCP and SCTP. UDP and DCCP would be a plus.

Audio is also a component of media in general. It would be even better if this design is treated as a multi-media design. Then you might have some hope of actually keeping audio and video in sync (something too many multi-media sources have failed to do) for content that has both.

Re:Then I suggest a new API and protocol

[QuoteMstr]

Someone with a five-digit UID should know that's unreasonably optimistic view of software development. Name one successful real-world system that was actually developed like that --- shiny and perfect on day one. If you actually followed your dictates and implemented that kind of process, you'd wait a decade for a new audio system to appear, and we'd be stuck with the current intolerable state of affairs even longer.

Re:Then I suggest a new API and protocol

[c0d3g33k]

I'll weigh in with my mere 6-digit UID and point out that your argument is nonsense if enough interest from the developer community can be marshaled. I will concede that the latter can be very hard, but you still paint a grimmer picture than you need to. The story of git suggests that it is very possible to 'start from scratch' and come up with something very workable rapidly. Why wouldn't the same be possible for the Linux audio stack?

Re:Then I suggest a new API and protocol

[QuoteMstr]

Because version control is a solved problem. Audio, apparently, is not. Plus, everyone agrees on the qualities a good version control system should have: on the other hand, nobody will be satisfied with an audio daemon that comes out of a git-like process. You'll have people who don't want the "bloat" of anything but one-sound-at-a-time-with-zero-latency, you'll have people complaining about power consumption, and you'll have people whine about it breaking sound (when in reality, it's the drivers that are broken).

Re:Then I suggest a new API and protocol

[Anonymous Coward]

And why can't we just settle with the OSS API?

I'd argue the OSS API is still one of the most supported. How do I know this? Well, I use FreeBSD and never had a problem with audio. FreeBSD has its implementation of the OSS interface in the kernel. I don't have any other sound servers installed. I'd say (but I am not entirely sure) the only things abstracting from OSS are gstreamer and Phonon.

I just can't believe that adding another API is the solution. One of the things where Linux audio outperforms everyone is the number of APIs.

Re:Then I suggest a new API and protocol

[Skapare]

Someone with a five-digit UID should know that perpetually staying with whatever is developed first means an end to progress. I don't profess that "doing over" makes things perfect. It has the opportunity to make things BETTER (though admittedly, it also has the opportunity to make things WORSE).

As for your selection of Perl 6 for an example ... I dismiss your example and replace it with a different language entirely (not specified, so as to avoid attaching a language debate to this thread). My point is that Perl 6 is neither a complete overhaul (if it was, it wouldn't even be called Perl anymore), nor the kind of design process I even propose.

History does have many examples of many ideas reaching their limits, and being replaced by an all new design. It doesn't mean the idea was necessarily bad for its time. In many cases the new design might not have even been practical when it first came out.

Re:Then I suggest a new API and protocol

[Skapare]

Audio is UNDERSTOOD. It is effectively a solved problem in the technical sense. The difficulty of this is that there are still people that think something someone else wants is not worthy of being implemented.

Actually, git isn't even the end of version control. It is certainly an improvement over the past. But just because the basic problem is solved, and understood, does not mean we can't improve it even further. I've found hg to work even better. And I still see ways to potentially improve hg (though I do not personally have the time to dive in and just do it myself).

Re:Article is doomed to failure, but PulseAudio is

[5plicer]

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

I highly doubt that: Windows and OS X have completely different audio architectures.

Re:Article is doomed to failure, but PulseAudio is

[Rockoon]

And as I said, most applications seem to have this built in concept of "latency == bad"

Wrong.

Most applications have this concept that it doesnt matter, because for most applications it doesnt matter. You even went ahead and explained this yourself. Please.

There are *some* applications where Latency = Very Very Bad.

Will PulseAudio support them, ever?

That is the chasm Linux audio is standing in front of. On the one hand you got this nice group-think that the design of the audio api should have all these rerouting features and so forth, and on the other hand you have applications that absolutely cannot work with high latency.

I do not think that its in the best interests of the linux community to tell the people who demand high performance audio to go fuck themselves. I believe that its in the best interests of the linux community to get a nice solid high performance api working, then work to spread it to every distro until it is as ubiquitous as posix.

Only then should you build your monumental kitchen-sink api, and only do so on top of that now standard high-performance api.

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

[QuoteMstr]

then work to spread it to every distro until it is as ubiquitous as posix

Do you have any clue what you're talking about?

Re:Article is doomed to failure, but PulseAudio is

[QuoteMstr]

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.

Forget the article: did you even finish the excerpt? Your post is just more know-nothingism from the audio crowd. 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; and it provides flexibility you'd expect from a modern operating system.

(Apparently, all these people here who never run more than one audio application over one output channel under one user would be happy back in 1995.)

Re:Article is doomed to failure, but PulseAudio is

[jelle]

And slow down interactive response such as seeking?

No, latency is _not_ good.

Wow

[ledow]

Okay, I don't use a normal "desktop" distro, so PulseAudio has pretty much slipped me by completely (good old ALSA, not broke, ain't gonna fix it) but the one line that scared the crap out of me was:

"For example, if a video is running in one application the system should automatically reduce the volume of everything else and increase it when the video is finished."

Er no. The system will damn well do what I tell it to. My volume levels are *my* domain, them being a user interface. I don't mind it being capable but the word "automatically" scares me. It also seems to add extremely unnecessary levels of complexity to a desktop system by literally abstracting every sound source and every output device (including network-audio) into separate entities - isn't the idea of a sound daemon of any kind to *merge* those entities seamlessly? That was the bit I liked hearing about PulseAudio - integration of esd, arts, alsa, oss, etc. into one place, but to then abstract out every program with it's own volume control seems daft (and adding another step into the "where the hell is that volume control that's making it so loud" process).

You know what I want? One damn volume control that controls the final output to my speakers (multiple independent speaker sets is an advanced configuration that I and most other people really don't care about, hotplugged or not). And everything *behind* that should be filtered and normalised so it's all the same volume unless I *specifically* say otherwise. Audio professionals are working *with* sound, so they have the tools to do what they like. 99% of desktop users just want their IM notifications to be heard as well as their MP3's without having to play with sliders all the time.

linux guy doesn't care about non-technical users?

[Overunderrated]

Newsflash!

Re:Article is doomed to failure, but PulseAudio is

[RiotingPacifist]

+1 irony, you post bullshit FUD that has nothing to do with what OP is talking about, yet your sig bitches about SCO, the sad part is you get modded insightful round here!

I have problems, and I'm a sysadmin!

[Gunstick]

yeah, pulseaudio not working here.
Well it works almost all the time though, after I installed about 20 more pulseaudio packages not installed by default in ubuntu.
Still it happens that suddenly either the pulseaudio deamon looses access to /dev/dsp or pulseaudio refuses connections and I have to restart it. Effects are: webbrowser hanging because flash can't send audio. Or youtube videos playing, but in silence.

If /dev/dsp is not supposed to be opened directly by user programs why the hell does it still exist?
Why is there no /dev/pulsedsp and then the /dev/dsp is created by pulseaudio and manages all the legacy crap.
It's all bad design, really.

Also a good distribution should include only compliant audio applications (including IM and stuff) or adapt those programs so that they work with the chosen audio infrastructure. Hey ubuntu, you want the desktop, well get your sound working!

This text typed on a dell PC where there is only sound on the headphone jack but not on the internal speaker (yes it's connected!)

Re:I have problems, and I'm a sysadmin!

[alukin]

I have problems with PA, and I am an expert in Linux sound. I solve problems with PA removing the beast as soon as I discover it. No smiles.

Re:Article is doomed to failure, but PulseAudio is

[Rockoon]

Yes. Quite a bit of clue.

Do you have an arguments that you would like to make, or is your claim to fame here that you just want to insinuate that you have one?

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

So, an audio framework telling a video player "Hold on a sec, I'm buffering" is OK?

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

"I also ensured that it is very easy to turn PA off if you don't want it"

Keep the good work : best thing about PA !

For the record, I never got it to output ANY sound on any Mandriva I tested, on which it was... never really got it working on any distro, by the way (either with integrated soundcard or on my M-Audio Delta Audiophile). Closest thing was on Fedora, where it was at best barely spitting some bits of sound each few seconds (at worst, no sound at all).

So, yeah : keep working on the ease of PA deactivation. Really keep on.

WTF?

[argent]

Remote Procedure Call is another 'WTF?' claim -- you know Unix is very big on these things called Pipes, right? What the hell do you think those are?

They're not RPC. RPC is a mechanism to model access to remote resources analogously to access to local resources. To hide the mechanism (pipes, sockets, packets, connections, TCP, NetBIOS, OSI, ...) under a synchronous call model.

Pipes are streams, at least on UNIX (I don't know what other operating systems might put under that name, we're talking about UNIX pipes here). They model access to remote resources through a serial I/O model.

The RPC model and the stream model each have their strengths and weaknesses, which I'd be happy to discuss if you want, but the point is that they are not the same thing at all.

Calling pipes "RPC" is a complete WTF.

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.

ALSA devs are to blame for this mess

[Anonymous Coward]

PulseAudio is a source of many problems, yes, but it's no worse than all the other bandaids, like Esound, NAS, etc.

The reason why all these bandaids were introduced is because ALSA devs continue to refuse to make the kernel audio devices multi-open. In any sane world, opening an audio driver a second time would not fail or hang or stutter, but instead would AUTOMATICALLY connect all audio inputs to a kernel software mixer and hence work transparently.

Instead, because the ALSA devs are utterly insane, they require dmix to be configured up for ALSA apps in user-space, and provide no direct multi-open driver for legacy applications. As a result, audio in the Linux world is just borked. It doesn't have a hope of working in the presence of the billions of legacy audio apps or with proprietary crap like Flash for example (and if Flash works then something else won't, or a second instance of Flash will break, etc). And that's why crap like PulseAudio gets invented as a bandaid.

Sure, PulseAudio is a royal pain, but the people who deserve the worst kicking are the morons at ALSA, who for years have refused to add kernel multi-open to their audio drivers for no sensible reason.

If ALSA continues along its current path of total myopia, the best solution for Linux is probably to scrap ALSA and replace it with the latest OSS. Then no bandaids will be needed.

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.

It may be in distros, BUT...

[Murpster]

How many people install a distro with PulseAudio, then disable it? I one of the first things I do on a new Fedora install is rip out PulseAudio. I know many many other people who do the same. Just because some Linux flavor "adopts" it and installs it by default, you can't assume that everyone using those distros actually uses the piece of crap.

Am I the only one who has had no issues with......

[spockrock]

pulseaudio?? I installed it before it was the default sound daemon in ubuntu and have had very minor issues, the only issues experienced were with flash, which was quickly resolved and networked audio over wifi, which seemed stutter but over Ethernet sound was perfect.

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.)

Re:Use pinfo to read info pages

[Anonymous Coward]

No. I just said: I did not want that. Nothing there is a bonus at all. I have a favourite pager, and man kindly uses that. Both come standard with the system. info is for emacs lovers and pinfo is an obscure add-on, and also captive. Both fail to gracefully bail out if the info I asked for is not there. Neither falls back to my favourite pager when both insist on showing a manpage (that I did not want them to show). I don't want silly highlighting and all those fancy other things.

Mainly I want one thing: Proper manpages. texinfo quite simply fails to improve on the format, it also quite spectacularly fails to improve on the workflow, and does much worse on the quick-lookup use case that is essential to reference works. On top of that, as soon as you want to print anything --something man does splendidly right out of the box to PS, the standard unix printing intermediate format-- you need a hundred or so extra megabytes for a typesetting system that is massive overkill for this purpose but the texinfo printing glue believes that `paragraph at once' is all you need, thus you end up with what is actually much worse and positively atrocious typesetting in an oh-so-nice computer modern.

Yes, gnu software at its finest. Very clearly not unix. No, I don't want gnu-not-unix, certainly not texinfo. Not pinfo, not info, not texinfo-util-devel-extra-plus-debug. Didn't you hear me the first time? What part of I DO NOT WANT IT didn't you understand? Let me be extra clear then: I do not want texinfo, nothing of it. Not info, not pinfo, not qinfo, not ginfo, not kinfo, not ice-info-fox. Did I mention I do not want texinfo? I do not want texinfo. Now you know. Kindly read the memo in completo next time.

Re:Use pinfo to read info pages

[shutdown -p now]

I hate info with a passion, but I actually use pinfo just to read manpages. It really is that much more convenient than man (if only because it lets you navigate the references to other pages).

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

... 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...

Pulseaudio is not meant to be used as a realtime application for recording your guitar. There is other software for this.

Are they deaf!?

[ThePhilips]

... and says such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people.

I see. That clears the confusion to me. PulseAudio was never tested by people who can hear. And the quoted "technical people" are most likely simply deaf.

Because even on most $5 "Made in China" speaker one can hear the cr*p coming from PulseAudio and even jitter of ALSA. Yes, $5 "Made in China" speakers improved that much in past years. And the PulseAudio creators must be really deaf to not to hear all the sh*t PulseAudio does to sound.

P.S. OR they test it exclusively with YouTube. That might be another explanation.

P.P.S. And do not get me started on PulseAudio configuration nightmares... (They blatantly discarded lessons of ESD/Artsd fiasco.) Configuration tools are simply dysfunctional and just as before trivial task of switching from one sounds card to another is a chore involving config editing on command line and couple of reboots.

Re:Are they deaf!?

[alukin]

PulseAudio was never tested by people who can hear?
No, PulseAudio was never tested by people who has head.

Re:Are they deaf!?

[AdamWill]

Can't speak for anyone else, but _I_ test PulseAudio with a Chaintech AV-710 S/PDIF output to a Firestone Audio Spitfire DAC, to Firestone Cute headphone amp, to Grado HF-1 headphones. That's about a $800 headphone stack right there.

Re:Article is doomed to failure, but PulseAudio is

[BrentH]

Lag==Latency, and those are not the same as a buffer. I didn't know Pulse had a buffer, but from my standpoint it certainly acts like latency/lag, because I don't want an extra 200ms between me changing a tune and hearing the change. Never mind playing games like FretsonFire (or games at all, which shouldn't be buffered ever and should be as low latency as possible). Why is it that Windows and OSX seem to get this right (you can call then many things, but not deficient in the audio area)? I simply cannot understand how you could think high latency is certainly good, thats simply never ever the case.

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

[Talchas]

So what if I just want to have one application's sounds be louder? Or what if I don't have an amplifier or external speakers (hint, laptops often don't have a dedicated hardware volume control)?

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:I disagree

[Improv]

Alternatively, you can have it both ways - let people type IDCLIP to disable clipping and retain full volume!

Re:I disagree

[Khyber]

"Computer speakers have a volume dial"

What... the... fuck? Are you insane? Most plug-in sets of computer speakers that I've EVER owned had no volume controls, let alone an on/off switch. The polk audio speakers I have hooked up right now are pure speaker and pure wire, in the back of an old HP 753n Pavilion desktop.

I remember rigging two Pro-Thump 8" subwoofers, and four speakers salvaged from busted radios, into two three-way cabinets, and hooking them right into the back of an ISA Bus SoundBlaster 16 with a rigged 1/8" headphone jack plug. AND THEY GOT LOUD AS SHIT. Most other speakers before that had no controls, they just plugged into the back.

We didn't need powered amps for speakers until PCI bus and crap onboard integrated sound. It can't handle the power.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Power consumption in alsa: In order to enable this mode you need to disable interrupts and then deal with the filling of the audio buffers via some kind of timer mechanism. This approach also requires that the whole mixing buffers are rewritten when needed (this is across all applications). This needs some kind of central process to manage all the audio from all applications, or a "sound server". The likelihood of this even occurring has to be offset with the overhead of remixing etc etc. but the tradeoff is generally fine unless you are skipping forward/back in audio tracks all the time etc.

The argument about writing for the most common path is not one I'd personally agree with. You have to design the architecture to handle all the cases that will be thrown at it. Sure, maybe make the common case pipeline a clear run through your architecture, but you can't really do things fundamentally different in difference cases. Typically a problem occurs when something changes half way through, you cannot tear down your "special setup" and restart in "generic setup" without letting the user know with a pop and a click.

0 == no attenuation in my book, not mute. A volume of 0dB is pretty much the max it can be.

And -inf dB attenuation != mute either. My volume can be pretty near 0dB and I can still have the thing muted... If I hit mute twice, I don't want to lose track of what my volume was at! In my book, mute state handling should be totally separate to volume. How it's presented to the user via GUI tools is perhaps another question tho'.

The fact that audio cuts out when you switch to a TTY is the domain of console-kit. There used to be a way do disable it via HAL but as HAL is dead now, that no longer seems to work, but I'm sure there is another way to do it. It's basically tweaking the console kit policy.

Re:Article is doomed to failure, but PulseAudio is

[Tubal-Cain]

OSSv4 or older flavours simply does not have the API to deal with a modern linux desktop, plain and simple.

And yet for me it's the only system that will play multiple audio files at one time. ALSA/PA give the entire sound card to that paused youtube video loading in the background.

Flexibility vs the common case

[nostriluu]

Pulse Audio's flexibility sounds cool. But I just want my 5.1 audio setup to work. It doesn't. Right now it's completely broken, audio skips and I have to use low level programs to get surround sound. The audio system should just pass the raw stream through to my very capable receiver. When I try to use PA to do this, the receiver shuts down. I've spent hours trying to configure this through random "guides." I'm technical but I've grown very tired of tweaking, I want a distro that just works for a very common case - multimedia.

Re:Flexibility vs the common case

[AdamWill]

that's actually a case where PA is making things much better. with raw ALSA you have to either flip an obscurely-named mixer switch (which is actually a driver hack...) or create a custom asoundrc to do S/PDIF output. With recent PulseAudio and gnome-volume-control or pavucontrol, you can just select an S/PDIF output profile from a drop-down box in the volume control application (in g-v-c, go to the 'hardware' tab, select the device you want to do S/PDIF output on, and pick the appropriate choice from the drop-down box labelled 'Profile:').

This isn't in the last round of distro releases (Fedora 11 / Ubuntu 9.04 / Mandriva 2009.1), admittedly. It's in the next - well, it's definitely in Fedora 12, and should be in Ubuntu 9.10 and MDV 2010 if their stacks are recent enough. But even before it was fully-implemented in PA, it didn't make the situation any *worse*: you could make it work with PA using much the same tweaks you had to use with ALSA.

Re:Flexibility vs the common case

[nostriluu]

Thanks... I'll try Ubuntu 9.10 and see if it fixes my problems. I note that multichannel (ac3) encoded media is considered a "political" problem, while for the vast majority of users that would be more important than being able to switch from headphones to the neighbor's stereo.

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

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Lag != Latency. Lag is the time between two things that should be synchronised, but are not. Latency is the time taken between something going in to a black box, and it coming out.

If there is a buffer of 20 seconds, and I completely fill that up right at the start, the data going in will have between 0 and 20 seconds latency. The lag is completely different and as we have no idea what we're supposed to be synchronised with, I cannot comment about what lag could or could not be in this case.

It's this general misunderstanding that means that statements like: "I simply cannot understand how you could think high latency is certainly good, thats simply never ever the case." so completely wrong.

I'm not suggesting that games etc should have a ridiculously high lag between a visual event/user input and a sound event. Clearly this wants as close to lag=0 as possible. But you should really also consider that for many applications and use cases, latency IS a good thing due to the power savings it introduces, and thus the longer battery life.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

If that's what you see, then your setup is wrong. Blame the distro or blame the close source crap that we can't fix.

I can use Firefox to watch a you tube video and play it out via my Bluetooth Hifi while listening to music on my built in card and move all those streams around at will. Ergo, the problem is with your setup, not PA. Complain to your distro.

Re:Article is doomed to failure, but PulseAudio is

[advocate_one]

thanks for the heads-up... I'll wait and see for the next LTS release... Ubuntu might have got it right by then...

Also

[Sycraft-fu]

Worrying about network sound when it doesn't work properly locally is putting the cart before the horse. Though I don't see the need for a network transparent audio system (I mean I can play audio over a network without one just fine) I won't say it is something that shouldn't be done. What I will say is that if you are going to do it, fix the simple shit first. When you've got a rocking setup locally, then I'd love to hear about how you are going to make that work over the network. However if adding that network capability is going to cause trouble locally, then don't do it.

As you pointed out, most people just want a sound system that works well on their computers. This is obviously not an impossibility, Windows and OS-X do it without problem, and have for a long time. They also handle things like multiple devices, surround, devices being added and removed while a system is running, sample rate conversion and all the other things you might think to list. Finally, they do it all with a minimum of latency.

As such, show me that for Linux first, then show me it working over the network. Don't show me some broke ass thing that doesn't work well in a plethora of situation and claim it is "better" because it can do shit most people don't care about.

More features are NOT better if the features don't work well.

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.

Consequences are odd where misapplied.

[dbIII]

It's all very handy in the environment you describe but it can just be a source of weird bugs in a simpler environment. An odd one was multiple versions of Thunderbird, Seamonkey and even Netscape on gnome crashing every time the user tried to compose mail - no matter which version I put on there it just kept falling over if run locally but worked every time run remotely. The thing tried to make a noise, went looking for bluetooth hardware that didn't exist and then crashed the email client. Removing pulseaudio and reinstalling pulseaudio without bluetooth support fixed that.

Re:Consequences are odd where misapplied.

[colin_s_guthrie]

Well this is clearly a case where a bug needs to be fixed. A similar bug I had that lead to crashing was due to enigmail cocking up, even if I wasn't about to sign anything. In this case, chances are it's not even directly PAs fault, but rather some thing inbetween, e.g. libcanberra or similar, but without a full backtrace I can't comment further and say the bug is with the libpulse client or libcanberra.

Re:Article is doomed to failure, but PulseAudio is

[Buelldozer]

Very nice but...

I shouldn't have to spend hours flailing around trying to get audio working in the year 2009. I have yet to get PA to work correctly on any hardware and on some systems I haven't been able to get it working at all.

It's ludicrous. All the finger pointing in the world won't change the fact that with Kubuntu and ALSA my audio worked out of the box almost every time. With Kubuntu and PA it's never worked correctly if at all.

Frankly it's as bad, or worse, than getting an ATI video card to work correctly.

Between video and audio I gave up on K/Ubuntu. It just wasn't worth the headaches.

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.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

And this is yet again, lumping all the problems of a distro at the door of PA without *any* specific justification other than it was there.

This is the problem of Linux development in my opinion: a little knowledge is a dangerous thing - e.g. knowing enough to know that there is something called pulseaudio installed and removing it makes things work ergo it is at fault as opposed to all the configuration and setup that is *supposed* to go part in parcel with it.

I'm not saying that the problem *wasn't* with pulse itself, it's just that all too often people jump to the conclusion that it is when really there is no evidence for or to the contrary.

Until a proper investigation shows where the problem really lies, I keep an open mind.

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

It will be the standard if it stops sucking, otherwise. Kiss it goodbye, the hordes will choose what works for them (OSS4 for me). I could give a shit less about network based audio. If you can't make my recording studio work without latency and hissing, you're worthless to me. I don't care if that's "ignorant in the extreme" either. My choices are purely pragmatic. I'll happily toil in ignorance if it is productive.

Pulse Audio does not meet my needs.

If I wanted to use unstable, buggy audio...

[otis wildflower]

... I woulda stuck with aRTs.

Why can't anyone get this as right as *shudder* Windows?

Dare I dream of Mac audio?

Heck, why not just have a mixing driver for /dev/dsp that doesn't crash or drop out? That's probably what 90%+ of linux desktop users really want, and for the audio nerds let them deal with JACK et al on their own time..

Re:Article is doomed to failure, but PulseAudio is

[BrentH]

OK, if we use your definition of latency and lag (which is fine by me, I simply meant lag by latency before then), and if latency is there because of power savings, how much power /does/ it save? I havent seen dramatic improvements because of it, on my laptops (which I presume are the 'many applications and use cases' you're talking about, have you, eg are there benchmarks on this? Even so, Pulse certainly gives many users the perception of lag. Whether or not this is because of buffering or simply /is/ laggy, (which many of us infer) will you do anything about this? I use ALSA because for me it always Just Works, and in the cases Pulse does work, I percieve it to be laggy. No matter which way you slice it, there seems to be consensus on this, and I'd like to see stuff fixed. The 'laggy experience' Pulse gives me and many other together with the fact that every article I read on the subject moans about the bad design of the total software stack you use with Pulse, gives me the impression Pulse is simply too big and complicated. Now, the software itself I admit I don't know jack shit and just restate the comments of other devs, but can you comment on that anyway? Do you really think Pulse has a sane design? If I look at this article, it certainly seems to me OOSv4 has it right and Pulse not: http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html

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.

Re:Adobe's Linux sound bitching

[OrangeTide]

Don't worry, some developer will decide that Pulse, Jack or GStreamer sucks and rewrite it. There appears to be no limit to the number of times the wheel can be reinvented for Linux audio. Also I didn't realize aRts was already obsolete, I'm not surprised, but man I can't keep up with the changes.

Re:Adobe's Linux sound bitching

[Tetsujin]

Don't worry, some developer will decide that Pulse, Jack or GStreamer sucks and rewrite it. There appears to be no limit to the number of times the wheel can be reinvented for Linux audio. Also I didn't realize aRts was already obsolete, I'm not surprised, but man I can't keep up with the changes.

Well, I hear you there. I was kind of surprised when aRts went away, too - likewise when Gnome and KDE dropped Corba. I haven't been following Gnome for the most part so I was also surprised to see ESD went away...

Re:Adobe's Linux sound bitching

[21mhz]

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.

Move GStreamer higher up: it's a set of audio application building blocks that work on top of PCM audio interfaces. And it can abstract away, to some extent, dealings with both PulseAudio or Jack, or directly with ALSA or OSS.

Re:Adobe's Linux sound bitching

[Karl J. Smith]

Linux Weekly News has a nice summary of Linux Audio from the Linux Plumber's Conference:

http://lwn.net/Articles/355018/

"The history, status, and future of audio for Linux systems was the topic of two talks--coming at the theme from two different directions--at the Linux Plumbers Conference (LPC). Ardour and JACK developer Paul Davis looked at audio from mostly the professional audio perspective, while PulseAudio developer Lennart Poettering, unsurprisingly, discussed desktop audio. Davis's talk ranged over the full history of Linux audio and gave a look at where he'd like to see things go, while Poettering focused on the changes since last year's conference and "action items" for the coming year."

The slides from the talks are also available as one LWN commenter pointed out - http://linuxplumbersconf.org/2009/program/

Re:Adobe's Linux sound bitching

[Wonko the Sane]

Are you suggesting that people read the articles? You must be new here.

What he said...

[Tetsujin]

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.

Some people don't even think the words are "bad"...

"fail" is not a noun...

[Tetsujin]

Talk about fail.

Please, talk about failure...

Re:"fail" is not a noun...

[adolf]

Talk about *woosh*.

Re:"fail" is not a noun...

[Tetsujin]

Talk about *woosh*.

No, "whoosh" is when someone doesn't get a joke. "X is fail" isn't a joke. It's slang - and, IMO, a really stupid bit of slang. I know people aren't going to stop using it any time soon, but I still like to promote my own perspective on the subject - that saying "that is fail" is stupid.

Re:"fail" is not a noun...

[Aphoxema]

"fail" is not a noun...

Au contraire...

n.
1. Failure to deliver securities to a purchaser within a specified time.
2. Failure to receive the proceeds of a transaction, as in the sale of stock or securities, by a specified date.

Re:"fail" is not a noun...

[adolf]

Talk about dense, asshat.

It's my perspective that people who proactively oppose the use of slang are all asshats. It's a perspective that I like to promote whenever I can -- that condemning speech, of any kind, is stupid.

FWIW. HTH. HAND.

Re:"fail" is not a noun...

[Anonymous Coward]

No no, I like when people use terms like this, along with the nearly always capitalized "LOL" and the distinctive lettering of "noob". It makes them easy to identify, much like those white-trash, wanna-be gangsta copycats with the sideways cap, undershirt, and shit hanger pants with the underwear sticking out.

Thanks for the heads up, GP! I saw that phrase and saved myself from wasting valuable minutes reading your post.

Re:"fail" is not a noun...

[adolf]

FAIL. Parent was correct: "fail" is generally not a noun. "Failure" can more often be.

(Yes, I'm perfectly happy to attack my own improper use of language when appropriate, and also am quite capable of hypocritically using it anyway.)

Re:"fail" is not a noun...

[Aphoxema]

"Generally" is synonymous with "conventionally", and conventionally "fail" has come to be used as a noun.

Fuck the definition you read in your book, if we were judged by the English of our precursors we would all be laughably awful.

Re:"fail" is not a noun...

[adolf]

*shrug*

The real question here, then, is thus: Are we all FAIL or not?

Re:"fail" is not a noun...

[V!NCENT]

Please integrate with todays culture and keep up with the evolution of languages you try to speek...

Fedora Core 9 and Pulse

[OFnow]

For months every FC9 update would break sound (and there
was at least one update that broke sound every week). Either I could not listen to
YouTube sound or Skype would stop working. Or both. For a long time Pulse was
de-installed. Then I had to install it. Then I had to futz with controls (sometimes
system controls, sometimes things in an application).
Some weeks I could not get sound working till the next update.

Why is it such a nightmare?

Sure it is the distro's fault.. So? It's been really bad.

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.

Re:Article is doomed to failure, but PulseAudio is

[mhenley]

JACK is designed for music production and very low latencies. It was not designed to keep batteries running on a portable device. It was not designed to "Just Work". I do not know all the pro's and cons to be honest. Typically only software for audio production interfaces with jack. It is possible to have PA as a Jack client. Therefore you can run jack and have PA as inputs so you can keep JACK going all the time and disconnect PA when you want to record. I was not able to get this stable on my system. i filed bug reports but was not able to meet the dev's report requests (running PA under gdb kills jack before you get interesting output). I have seen reports that it is working much better now. Matt

Re:Article is doomed to failure, but PulseAudio is

[alukin]

The same situation with me. But I solved it easily. I removed PulseAudio, cleaned things out and Ubuntu studio rocks! Do "aptitude purge pulseaudio" and you'll be on pure ALSA with all your Ubuntu fun up and running.

Re:Article is doomed to failure, but PulseAudio is

[alukin]

PA is so buggy itself and with Ubuntu installation, that it can not easily step back and allow Jackd work properly. The only solution is to remove PA.

Fuckin Hell

[Anonymous Coward]

cat > /dev/dsp

DONE

Ubunters are stupid to get it right, who's smart?

[alukin]

So, Lenart says that Ubuntu guys are so stupid that can not get PA right in 3 consequential releases. Who's smart to get it right? I spent a week trying get it right on Ubuntu 8.04, then on Fedora 10 and found only one solution. Get rig of PA and be happy.

I use recoding tools, MIDI tools and other music soft and PA drives me just crazy because it can not allow normal work of jackd.

So if Ubuntu guys are stupid, Fedora guys are stupid, and I am stupid, the only smart guy is Lennart. Let's make him a President of USA!

Rediculously complex!

[guygo]

I am not a novice at this stuff, but neither am I an expert by any means. However, when I can't make heads-or-tails of all the config files it seems to take just to get sound working, it demonstrates to me why Windows is still leading the market. It figures out what hardware it has and configures it, period. Why is this so difficult for Linux developers to understand? Not all of us have the time nor expertise to mess with all these layers of audio crap. I just want to hear sounds from my computer! If people had to jump through these same hoops just to see an image on their monitor, I bet something would get done. Why not with soumd? Rediculous.

Re:Article is doomed to failure, but PulseAudio is

[tom17]

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!)

I'd like to try this out. I did a brief search for PA streaming via UPnP to a PS3 but didn't find anything. Could you point me in the right direction?

Thanks,

Tom...

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

I am amazed by the amount of hate being thrown here. Thank you for some clarification on a number of issues. When PA was first introduced into Ubuntu, I had some issues with it, but by the next release it worked perfectly for me with the default install. When I built my primary machine, I was very careful about what hardware went into it. I had a nightmare of a time trying to setup my audio a very particular under windows (when I still used windows years ago). In my (evidently lonely experience) PulseAudio works amazingly once it is setup. While getting it just the way I wanted might take a little bit of time, it is FAR better than my experience under Windows where opening or closing an application, plugging in or unplugging an audio device could reset or simply break my configuration. Of course it would be nice if everything just worked the way I want them to work, but it probably isn't what everyone else wants. Anyway, I am VERY happy with PulseAudio and just want to say thank you for your contribution, even if others won't take five minutes to google their problems.

Re:Article is doomed to failure, but PulseAudio is

[RiotingPacifist]

This approach also requires that the whole mixing buffers are rewritten when needed (this is across all applications).

If computers running apps using pulseaudio's alsa emulation save power then why would all apps need a rewrite if this were implemented in alsa.

Perhaps i am misunderstanding this but currently I think what your describing:
app(s)->pulseaudio(mixes & buffers) ->ALSA->hw
I fail to see why this is better than
app(s)->pulseaudio(mixes) -> ALSA(buffers)->hw
I'm not suggesting that you do complex mixing in alsa, just that the buffering could (and as its a hardware related feature, not an audio one, should) be implemented in alsa.

0 == no attenuation in my book, not mute. A volume of 0dB is pretty much the max it can be.

It may simply be a case that every sounds system's GUI tools (from alsamixer to pavucontrol) suck at representing that but it really needs fixing because everything else (from amarok to windows) gives users the control the expect 0% = silence (something that is even falsely claimed in pavucontrol)

this is one sad thread.

[Anonymous Coward]

Here we are, taking about playing sounds....

and the conversation goes from sound server choices to distros, to complex sound server software, buggy software, and then people with bad attitudes, and then goes all the way down to kernel latencies, real-time software, complex interfaces/APIs and multithreaded programming!

SAD!

Developer or user, I can go to my Windows or OSX box and merrily play video, synced with my sound and no problems, or I can play my internet radio and surf heavily with no problems. And write software to do audio mixing/fades with zero problems... with hardly any pre-configuration.

If I need to know a complex API, how the kernel works with real-time needs and have apps that constantly break my audio subsystem... What does that say about the state of Linux audio? Sorry to sound like a broken record, but it sounds pretty messed up to me as a 'developer lightweight'. The way Linux sound is being handled really helps bring it down a full notch compared to Windows and OSX and that's bad since Audio and Video are pretty much the things that can put Linux on top as a F/OSS offering, otherwise, it will always be a niche thing that corporations fork to create something that does work (Android and OSX for example).

At least video playback is getting better.

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

That's how my Linux sound works ... and it sucks. Whenever I press play, the video plays for a few seconds and then the audio kicks in. When I press pause, the video immediately stops, but I get to listen to the audio for a few more seconds.

And that's supposed to be a good thing?

The short answer

[petrus4]

So after my last bit of flamebait in this thread, I finally went and read TFA, and the nature of the problem immediately flew out and hit me in the face.

I'm sure Mr Poettering has extremely positive intentions, fundamentally; however the single thing he is guilty of here, is a violation of McIlroy's Law.

"Do one thing, and do it well."

The article mentions how Poetter has included multitudes of magical features which, on the face of it, sound absolutely wonderful. Everything including the kitchen sink has seemingly been added.

However, there's just one little problem.

Not all of us are audiophiles. Not all of us (in fact hardly any of us) need to be able to swap sound devices mid stream. Very few of us need client/server sound playback over a network, either.

All most of us really want, is something which will play our wav files, mp3s, and the soundtracks of our movies, in such a way that we can hear them well, without crackles, hisses, pops, or latency issues.

This apparently doesn't exist for Linux at the moment, so if the love and adulation of thousands of Linux users is what Mr. Poetter seeks, he doesn't need to give people all these extra features.

All he really needs to give us, is smooth sound playback on the single, local sound card we have in our machines. That's all.

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

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.

Games.

I click the mouse - I want to hear the gunshot and see the muzzle flash immediately.

Re:Article is doomed to failure, but PulseAudio is

[DMiax]

fast forwarding will require rebuffering? neat...

Re:Article is doomed to failure, but PulseAudio is

[Tetsujin]

So, an audio framework telling a video player "Hold on a sec, I'm buffering" is OK?

If the video player knows how to deal with this, then yes. :) Being informed of this state is better than not being informed of this state.

There are cases (network streaming, primarily) where a certain amount of latency is unavoidable. In such cases, performance is best if the applications can support this scenario, too. Some applications can tolerate this scenario very gracefully (again, video playing being a good example) if they are written to handle it. Others (like games, as another poster mentioned) cannot.

To say it more clearly, perhaps...?

[Tetsujin]

Lag != Latency. Lag is the time between two things that should be synchronised, but are not. Latency is the time taken between something going in to a black box, and it coming out.

Lag is one possible effect of latency - but one that can be managed or negated in some cases by accounting for the known latency.

You lucky

[Mateo_LeFou]

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

You lucky bastad!
As soon as *I* got rid of pulseaudio, my sounds stopped working entirely. And my wireless. Headscratcher there:
http://ubuntuforums.org/showthread.php?t=1258063

HTML tags rock!

[Tetsujin]

then work to spread it to every distro until it is as ubiquitous as posix

Do you have any clue what you're talking about?

Do you have any clue what you're talking about?

Do you have... any... clue... what you're talking about?

Do you ha ve any clue wha t you're talking about?

Re:Article is doomed to failure, but PulseAudio is

[Tetsujin]

If that's what you see, then your setup is wrong. Blame the distro or blame the close source crap that we can't fix.

I can use Firefox to watch a you tube video and play it out via my Bluetooth Hifi while listening to music on my built in card and move all those streams around at will. Ergo, the problem is with your setup, not PA. Complain to your distro.

Actually, another possibility is that all his applications use /dev/dsp for their audio needs. Alsa only supports one /dev/dsp application at once, I believe, and I think Pulse is the same unless you use the padsp wrapper. Thus, running flash would tie up /dev/dsp, and any other program trying to use sound (via /dev/dsp) would fail. On my systems I use alsa with dmix - which means I've still got the one-program limit on /dev/dsp, but just about everything I use other than flash uses ALSA...

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

[colin_s_guthrie]

/me laughs at the way /. has trimmed the subject to add the Re: prefix :p

You cannot separate the mixing from the buffering like that. Consider two apps, both playing audio tracks (it will sound terrible but let's not think about that!). Both apps have fed 10 seconds into the buffer so they can "spin down" and save power. All well and good. So the output is mixed and fed to the device buffer with the highest possible latency it supports. Again, all good. Now the user suddenly skips a track on player A. What happens here is that we have to throw away the 10s of pre-mixed audio, keep Player B's audio but remix it to new content provided by player A's decoding of the next track. So the mix+buffer has to be kept together, so that the buffer from a given app is not thrown away until we known that it's spent. AFAIK, these buffers can be passed in to PA under zero-copy and are only copied when the audio is mixed and then dumped into the device buffer. i.e. it's very low overhead.

As for the "implemented in alsa" stuff, it sadly isn't really a valid comparison. If it *were* implemented in alsa, we'd first of all need some kind of daemon to run and handle this mixing for us. We'd need something that has exclusive control of the real underlying hardware so that it can disable interrupts on it and feed the data into the device buffers under it's timing control, regardless of whether applications start or close inbetween. In the end you'll just design PulseAudio all over again but call it "alsad" instead. So the whole exercise is rather pointless!

And as for the comments about representing sound controls in GUIs this is actually a pretty complex task, especially when you take the concept of flat volumes into consideration. For every app there are effectively three volumes kicking around but it will only ever make sense to show the user a single unified volume.

When it's back online (currently that service is down due to Trac basically not handling things!) this article should be insightful: http://0pointer.de/blog/projects/writing-volume-control-uis.html

Works fine for me.

[kementari7]

I don't know what the problem is for everyone else here, but I have yet to have any problems with PulseAudio. It "just worked" as the default on Ubuntu and Kubuntu 9.04, even in virtual machines. Before PulseAudio, I had to dig into config files to get my sound card working, and if I didn't do that, only one application would have sound at a time. So maybe I am missing something, but from where I am sitting, PulseAudio is definitely an improvement.

Re:Article is doomed to failure, but PulseAudio is

[plague3106]

Interesting... while so many distros got sound right prior to PA, they all mostly now have a problem with PA in the mix. If all of your users are doing things the wrong way with your application, its probably your application that's at fault.

Re:Ubunters are stupid to get it right, who's smar

[AdamWill]

Fedora and Mandriva have the best PA implementations, according to the developers. Fedora 10 has a pretty old PulseAudio, by the standards of development (PA development is quite rapid, in partly to implement all the bug fixes people in this thread insist Lennart isn't interested in writing). F11 is better, and F12 will be rather better than that. F12 Beta comes out tomorrow. Mandriva 2010, which is nearly released, should be good also.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Flash also uses ALSA. I'm not sure why your version would be using /dev/dsp. Mine certainly uses ALSA.

What is a common problem on distros is installing 64 bit browsers but relying on 32 bit plugins.

When combined with PA under the default setup (ALSA redirected to PA), you need to also remember to install 32 bit versions of: libasound, alsa-plugins, libpulse. If you do not, then the firefox's use of ALSA will fail and (I'm guessing now as the source is closed and I can't look) Flash will fall back to OSS.

Like I say, the distros play a big part here. If this is the setup they distribute, they need to think about this kind of thing.

Also the 1 device per /dev/dsp can be solved by kernel 2.6.32 (maybe) + Fuse 2.0.x and osspd. More info here: http://www.kernel.org/pub/linux/kernel/people/tj/ossp/ when combined with a pulseaudio setup. It could be made to work without PA if someone wrote an appropriate proxy.

Just waiting for this kernel bug to be fixed: http://bugzilla.kernel.org/show_bug.cgi?id=14023

All that said, as OSS is disabled by defaul on Fedora, and other distros will follow suit soon, I suspect that most people will forget about OSS support before too long.

Re:Article is doomed to failure, but PulseAudio is

[AdamWill]

"I'd like to try this out. I did a brief search for PA streaming via UPnP to a PS3 but didn't find anything. Could you point me in the right direction? "

http://0pointer.de/blog/projects/oh-nine-sixteen.html

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

To be honest, I've not looked much at this specifically (hence my original disclaimer!). I just know the support is there. You essentially just run paprefs and tick the right boxes and your devices should show up. I'll probably have a proper play with this sometime soon, so if you're interested, subscribe to my blog and I'll post something about it when I've got more info.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Well, not really. It could point to a documentation problem or it could be to do with certain distros aversion to getting involved with upstream projects as much as they could.

There are numerous problems being represented that are all grouped under the same heading, and that then informs your "all ... have a problem with PA". Like I've said already, the majority of the problems lie with most applications creative use of the ALSA client API (which make it impossible for us to compensate for), the drivers not supporting accurate timing information that is needed for timer based scheduling, or poorly integrated distro. None of these (bar the last one maybe) is a "pulseaudio problem" per se. There are other problems that *are* of course (bugs get everywhere) but it's totally unfair to PA to group things up like that.

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

No reason, except that audio is often multiplexed in the same stream as the video (as in a DVD.)

Re:Article is doomed to failure, but PulseAudio is

[Tetsujin]

Also the 1 device per /dev/dsp can be solved by kernel 2.6.32 (maybe) + Fuse 2.0.x and osspd.

Yeah, I remember that appeared as a story on Slashdot recently. It seems a bit hackish in a way but I like it - accessing /dev/dsp seems a pretty straightforward way to output audio, and I like that Linux support for it is improving. ...I could've sworn Flash still used /dev/dsp... <shrug>

Re:Article is doomed to failure, but PulseAudio is

[Anonymous Coward]

Clients are able to notify PA to overwrite the rest of the large buffer slightly forward from a hardware playback pointer, so it's possible to stop (or modify) sound and video with a very short lag.

When playback is (re)started, it shouldn't lag much because player will start filling sound buffer as fast as possible (there should be a certain pre-buffer required though before PA starts playing) and will stop when 2s of the buffer is filled, and then get periodically woken up each second to re-fill the 1s fragment again.

For games or interactive audio that's of course not acceptable, but then they can simply negotiate short wakeup periods for as-low-as-possible latency, although obviously not as short with specialized tool like jack - I guess jack turns on audio card interrupts to get even lower latencies?

I'm not completely sure about all above, but that's how I understood it from Lennart's blog.

Re:Article is doomed to failure, but PulseAudio is

[plague3106]

If its not easy to figure out how to configure, its more than a documentation problem. I fail to see why anyone should be "getting involved upstream." It should be simple enough to figure out on its own.

You say its unfair to blame PA for problems, but most of those problems WERE NOT THERE prior to PA. I say its totally fair to blame PA.

Consumers don't care

[Stan92057]

Consumers don't care why it doesn't work,crash or whatever reason it becomes useless. They all want a product that just works,free or not free,makes no difference to them/me

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

This is why distros play an important job. Compiling your own kernel is a complex job that 90% of users shouldn't have to care about. Even with a shedloads of documentation, you still need to keep on top of kernel developments to ensure you're using the right options and the right approach. Ditto with configuring pulse. I don't deny that it's a complex beast to configure correctly, but that's why we have distros. Just like we vote in politicians to read policy and make decisions on our behalf (why everyone shouts "referendum" whenever anything vaguely complex comes up is beyond me - the people voting in referendums do not read the policy in question to make informed decisions - they read the red tops... insane), so we chose our distros to take care of this stuff for us. Users should not have to venture beyond a few ticky boxes.

And none of these problems were there before the Linux kernel, so obviously it's the one to *really* blame right?? Argument fail. :p

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.

All you really need to know

[steveha]

Here's all you really need to know:

The Linux world is converging on two sound solutions: JACK and PulseAudio. Both of them solve important problems.

When you want audio with absolute minimum latency, like for professional audio recording, you want JACK. You also want to be plugged in to the wall, not running on battery power, because JACK will keep your CPU busy.

If you want to run Linux on a modern laptop or netbook, you want PulseAudio. PA is designed to let your CPU sleep as much as possible, and thus save battery life.

I can hear some of you now saying "I don't want any sound daemon; I want to run my apps against the bare metal." In that case, I hope you never want to hear sounds from more than one app at a time. Modern motherboards tend to have very simple audio devices, with absolutely no hardware support for mixing audio, or even sample-rate-converting audio. You might have a single output device that accepts a single stream of samples at 24-bit 48000 Hz, full stop. "Oh, I'll just let ALSA Dmix handle it." Why is Dmix good and PulseAudio bad? Both are user-space solutions; and PulseAudio can do anything Dmix can do, plus more.

Or maybe: "I'll just run OSS4, which does sample-rate-conversion." Yeah -- in the kernel. Not the right place for it; kernel drivers are not supposed to use floating-point math. OSS4 tries to do everything in the kernel, and uses IOCTLs to set parameters in the driver. I don't want bugs in the audio stack to cause kernel panics; I want complicated audio mixing and conversion to happen in user space. (With realtime priority set, thank you very much.)

PulseAudio isn't perfect, but the basic ideas behind it are sound, which is why the whole Linux world is adopting it. We really do want a user-space daemon to do all the stuff that isn't appropriate for in-kernel drivers to do. If we wanted to throw away everything and start over from scratch, we would pretty much re-invent PulseAudio as the best solution; look at the user-space daemons used in Mac OS X and Microsoft Vista/Windows 7. Given that reality, how can we best proceed: by throwing out PulseAudio and starting over, or by fixing the remaining bugs in PulseAudio. I vote for fixing PulseAudio, and so has the rest of the Linux world, which is why PulseAudio is getting universally adopted.

The worst of the problems are over by now. To clean up the Linux audio mess, we have had to fix bugs in ALSA drivers, fix bugs in audio applications, fix bugs in PulseAudio, and get the distributions to setup PulseAudio correctly. It has been painful but we are well past the worst of it.

If you can solve your specific current needs on your specific current hardware by disabling PulseAudio, then fine, do that. But don't generalize this into thinking that PulseAudio should be removed from all systems and abandoned.

I think Lennart should release a new audio system called "Audio Daemon 7". Microsoft seems to be doing well with "Windows 7", by dropping the tainted name "Vista". At this point, the name "PulseAudio" seems pretty tainted. But PA itself is the Right Thing To Do and it's becoming the standard.

steveha

Re:All you really need to know

[colin_s_guthrie]

Nicely said :)

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:All you really need to know

[Wonko the Sane]

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.

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

I solved most of the problems you mention by switching to Gentoo (from LFS) and by compiling the kernel myself using the sources direct from kernel.org

Re:All you really need to know

[AdamWill]

so your modest proposal is that Linux stop 'aping Windows' as you put it and start aping FreeBSD instead?

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. I really don't know why people like you *make* posts like this. Do you really think it's the way to change anything? Do you honestly think Fedora developers or Ubuntu developers or anyone else is going to read a load of random vitriol on a comment thread somewhere and go 'oh my god, we've been doing it wrong all along! This guy knows the way and the light!"

I mean, honestly.

Re:All you really need to know

[Anonymous Coward]

it's #11u-max form linsux, i want to commend you for telling the freetard/linux youth community what they need to hear but are too big of bitches to take it like a man! GO, PETRUS4, GO!

Re:All you really need to know

[steveha]

Let's see how many of the Generation Y, amateur, snot nosed brats I get making a response to this post

I predict the answer will be: none. No one really cares what you think about this stuff. I sure don't.

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. Ubuntu didn't work for you, thus it must be junk for everyone. 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. You propose scrapping GNOME entirely, as if that were even possible, let alone a good idea. And you don't offer any facts or even reasoned debate about any of this. You don't like the design of GNOME, ergo it is "aping Windows", ergo it must be scrapped.

Whether you were trolling or serious, I have this bit of advice for you: grow up.

steveha

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

[Anonymous Coward]

this is completely true, petrus4. either debate correctly or stop arguing, i see that petrus4 picked debate correctly, and i suggest you do the same.

-#11u-max

Re:All you really need to know

[Anonymous Coward]

I wholeheartedly agree. There needs to come a point when people stop treating Linux and all of it's "revolutionary" but "not very well designed" with such emotional compassion.

It's an operating system. If something doesn't work right, you fix it, not defend it.

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."

Re:All you really need to know

[Anonymous Coward]

this is a very true statement,,, remember, YOU are not your OPERATING SYSTEM! some people treat linux like it was their first born child. please help develop and improve these "implemented features" instead of senslessly wasting time defending them.

-#11u-max

Re:All you really need to know

[steveha]

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 still not sure if you are trolling. If you are, well great, ha ha, you win, you got me to reply once more and waste more of my time. But this is my last response to you.

I called you immature because your writing is immature. Here are some specific examples, taken directly from your article.

You said, and I quote: "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." Really! Every single Linux developer cares nothing for technical merit; only for fads, and only you are wise enough to see this reality and tell it like it is. And we have to just believe you, because you have no examples to support this amazing statement. That was just your introduction; there were plenty more examples to come.

You said you had problems with Ubuntu, only you phrased it as "none of the major distributions are usable without giving me endless problems". Not only do you not even entertain the possibility that the "major distributions" might work for other people, you explicitly said "Linux in technical terms is crap, currently, and I'm fed up with the denial." I use Ubuntu, every day, on several computers, with no problems at all; why does it work for me and fail for you? I use Ubuntu because I don't have problems with it; I have worse problems with, for example, Windows. Am I in denial? Denial of what?

I wrote an article listing specific reasons why PulseAudio is the right thing for Linux right now. You did not refute any of my points, but merely stated "Stop writing propogandist garbage like this" and called me an idiot. Now seriously, is that mature behaviour?

You were abrasively dismissive of all the features of PulseAudio. Since you don't personally feel any need for those features, you declare them anti-productive and you pronounce them all "shit". Okay, here's one of those PulseAudio features that I like: when I plug in a USB audio device, it shows up in the PulseAudio list of devices; controls for it appear in the standard PulseAudio places; and with a click I can make it my default audio device. I happen to like this kind of plug-and-play functionality. I never had that before PulseAudio. Is that a "shit" feature? (It has nothing to do with "just plays audio. THAT'S ALL IT NEEDS TO DO.")

You suggested with no evident humour that GNOME should be abandoned, as if that were even possible, for no clearly-stated reason; you made a side comment about "aping Windows" which apparently you felt sufficient explanation. You made the incredibly stupid comment that GNOME needs to use dotfiles; I have news for you, it does, and you can edit them with a text editor and everything. GNOME did wrap the dotfiles in a system that is superficially similar to the Windows Registry; there is a daemon that manages settings, so that if two processes each write a settings change to the same config file, there is no race condition that could clobber one of the settings. In other words, the GNOME guys kept the one good feature of the Windows Registry, while rejecting the fragile opaque binary file format that is the Registry's Achilles's heel. Is that a bad design? Does it "bog everything down"? If so, then how does it bog everything down, and how do you know this? Have you run benchmarks?

You ranted about both Upstart and the Ubuntu module loading systems. What specific problems do they have? Why are your proposed alternatives better? Have you demonstrated that you understand why Upstart does things as it does? Here, check the Wikipedia page for Upstart. Read the Rationale. How does the classic BSD-like init system handle hotplug events better than Upstart? What is the advantage? Upstart is faster than the old SysV init system it replac

Re:Article is doomed to failure, but PulseAudio is

[ShawnX]

Colin, that's fine and dandy but... Your daemon can't even handle the fact when I use konsole and press backspace to trigger the beep several times will coredump the server. I will continue to remove PulseAudio from my systems until 1) its CPU usage is reasonable 2) It can let me control my hardware properly. Especially for me where the HW has no PCM capture (I have to use ALSA + jackd + jack_capture to get around this problem) 3) It does not crash so much causing me no end of pain with multiple apps requiring audio. Frankly I wish someone would push/convince Linus to get OSS4 into the kernel and help us get rid of ALSA (deprecate it) and then strip PulseAudio down to just network audio ONLY. We've had enough crap in the Linux Audio subsystem for so long, it's time to do the right thing and chunk the whole shit out. I'll accept more pain if we get it right, finally.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Yeah, because *my* computer is so shit it can only decode the DVD audio in real time and there isn't any way that it could possible decode say 20 seconds worth of the audio, and pump it into the audio layer in anything under 20 seconds right???

This is *exactly* the point I'm making when people here the word latency, they assume completely the wrong thing. You go on to say "As such you need to keep latency as low as practical"... which is where I switch off, as from this comment it's clear you've not read my posts, so I'll just ask you to read them again.

Now, like I say, you do not want high latencies at all times. Certain circumstances mean that this is simply not possible, e.g recording sound and playing it back or some other interactive sounds, but there are also a lot of applications where it certainly is a good thing.

And all this "windows has done this for years" crap people keep spouting, should read up about some of the "new" features in Windows 7 audio stack that are features PulseAudio has had for a long time! They are playing catchup.

Re:Article is doomed to failure, but PulseAudio is

[AdamWill]

"You say its unfair to blame PA for problems, but most of those problems WERE NOT THERE prior to PA. I say its totally fair to blame PA."

Yes, they were. You not knowing they were there is not the same thing as them not being there.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Colin, that's fine and dandy but...

Your daemon can't even handle the fact when I use konsole and press backspace to trigger the beep several times will coredump the server.

Really? Your system sucks then because on mine it works fine! Have you submitted a backtrace for this issue? Even a bug report?

If you haven't then the bug doesn't exist, plain and simple.

1) its CPU usage is reasonable

Well, on my system (4 year old core2duo) it sits between 0 and 1% even when playing...

2) It can let me control my hardware properly. Especially for me where the HW has no PCM capture (I have to use ALSA + jackd + jack_capture to get around this problem)

Not heard of any problems here but is there a bug report about this?

3) It does not crash so much causing me no end of pain with multiple apps requiring audio.

I'm not experiencing any problems. It's been pretty stable for me for quite some time? What version have you been using?

Frankly I wish someone would push/convince Linus to get OSS4 into the kernel and help us get rid of ALSA (deprecate it)

If you even had a tiny clue about things, you'd realise how ridiculous this statement is. OSS is old news. The API is not going to help us move forward. Have you even seen some of the stuff from the latest Linux Plumbers conference? Paul "Jack/Ardour" Davis summary is probably the best one I've read about why OSS is not sufficient and these are decisions that were made years ago... where on earth do people get this "OSSv4 causes world peace and solves every problem ever" option from? They've clearly never actually *looked* at things for themselves that's for sure.

We've had enough crap in the Linux Audio subsystem for so long, it's time to do the right thing and chunk the whole shit out.

Yeah because that kind of code writes itself right? All we need to do is get everyone to catch a fairy at the bottom of their garden and then stuff it into their CD drive... the code will be there by morning!

There are probably about four people working on linux sound as a paid job... Lennart, Takashi, Jaroslav and Paul... Maybe a few other too, but typically in very specific disciplines/hardware, but certainly none of them are going to start working on OSS that's for sure. So where is this magical work going to come from?

I'll accept more pain if we get it right, finally.

This is us getting it right and this is that pain.

Re:Article is doomed to failure, but PulseAudio is

[Wonko the Sane]

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/

Desktop environments need to ensure they integrate nicely with PulseAudio. GNOME is obviously doing this, but KDE is lagging behind. I do hope to rectify the latter situation personally, and have a pretty clear roadmap to making this happen – it’s just a matter of finding the time to do it!

Do you publish patches or a git tree so that interested users can try out your changes?

Re:Article is doomed to failure, but PulseAudio is

[Eil]

What most people quite often fail to realise is that Latency is Good.

In some situations, but hardly all. PulseAudio needs to stop billing itself as a jack-of-all-trades solution to audio on Linux. Based on what I've seen, it's only helpful for use cases that few average users are likely to presently encounter. It may become the basis for a large number of really cool things in the future, but right now it's doing more harm than good by shipping by default on the majority of Linux distributions.

Here's a useless anecdote: For months I was trying to get a decent music production system set up on Linux and it was an unmitigated disaster. No distribution had the correct mix of drivers, sound servers, and applications that would make everything just work. I should point out that PulseAudio was enabled by default on all of them, and PulseAudio had to be manually disabled on all of them just to get any sound moving through the system at all.

When I can play a chord on my MIDI keyboard and have it played, mixed, processed, and output through the speakers in less than 20ms with PulseAudio in the chain, give me a call.

Ubuntu has gotten much better since then, the people involved are engaging with us upstream and a really good people to work with

I take it you haven't yet read Lennart Poettering's blog post today. In it, he basically says that Ubuntu is repeating the same kind of bonehead mistakes with packaging PA in Karmic that they've done with ever other Ubuntu release so far: "Not good, Ubuntu, really not good! And I'll get all the complaints for this f**up again. Thanks!"

Re:Article is doomed to failure, but PulseAudio is

[defaria]

Here's the deal. You've over-architected it! Way before you begin worrying about networking audio, UpNP, Bluetooth, and ACLs of who can play a sound where get the damn fucking thing to work in the first place! Ain't nobody ever died by having more than one sound come out at the same time. More often than not, due to all of this unmanaged complexity, the end user has no sound coming out at all. I still haven't managed to get my mic working. How how fucking hard is that?!? There's one plug, one microphone and it's plugged in. Why then can I not record anything with it? Why should there ever be any more than one selection for this fucking mic?!? Answer: There shouldn't be. It should just work. It isn't just working and it has been just working on other OSes for quite literally a decade or more. Get the fucking basics working, down cold and (get this - a new word for you) RELIABILY FIRST! There. I feel better now...

PulseAudio sucks!!!

[cuby]

In Ubuntu 8.10 I had to install several add ons to control it and VLC sound was really broken. In Ubuntu 9.04 I had to remove it in order to listen something... Now in 9.10 I have sound, but I still don't have it over HDMI. PulseAudio and linux audio in general is a disgrace. It is in times like this I miss normalization and standards.

Re:PulseAudio sucks!!!

[AdamWill]

Why do you assume that PulseAudio is the reason you don't get any sound over HDMI? Did you get any sound over HDMI in 9.04 when you disabled PA?

Re:PulseAudio sucks!!!

[cuby]

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

Re:PulseAudio sucks!!!

[AdamWill]

actually (depending what version exactly 9.04 has) it probably does but isn't exposing that via any UI. 9.10 (and Fedora 12 and Mandriva 2010) include this functionality in pavucontrol. MDV and Fedora have it in gnome-volume-control too, I'm not sure which g-v-c Ubuntu 9.10 is shipping.

I didn't realize you were going from an S/PDIF output on the audio card, I figured you were actually trying to use audio via a video card's HDMI output (which is actually possible, as long as the underlying ALSA driver for that video card is present and working).

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Yup, just see the "About" page on my site. Some of the articles under the "KDE" tag have more info about the specific patches needed to make this all work. Feel free to comment etc. on the site and I'll try and get back to you.

You guys won't read Russian forums anyway, so...

[Anonymous Coward]

Hello, this is Linus Torvalds, and I pronounce PulseAudio as Pu.psh.sAddia...u..psh..

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Everything you've said is working FINE for me with PA. So whatever problem you're having, I can only assume it is outwith PA. As for "unmanaged" complexity... that's the problem right there? Did you just run "make install" or did you run a disto that managed the complexity for you? You should be doing the latter. If you distro doesn't manage that complexity for you, complain to them.

And for what it's worth UPnP and Bluetooth were very much plugged in later. The architecture allowed that to work with minimal hassle. For me that's good design, not over architecting.

context aware?

[jipn4]

For example, if a video is running in one application the system should automatically reduce the volume of everything else and increase it when the video is finished.

I'd be grateful if PulseAudio figured out that when Rhythmbox plays something, I might actually want to hear it, instead of routing it into some bitbucket. Heck, I'd be grateful if I could even figure out myself which of the dozens of screens and configuration options I need to press to make sound come out somewhere. As far as I'm concerned, PulseAudio is by far the worst component of the Gnome desktop.

All the big Linux distributions have adopted PulseAudio and it is an integral part of both the Palm Pre and the Nokia N900 devices, as well as Intel's Moblin.

Those devices are preconfigured for known hardware, so that's not so much of a problem. But on normal desktops, which often have multiple sources and sinks, trying to get sound out can be extremely frustrating.

So, where do they come from? Usually from users who are encountering problems when running PA in conjunction with particular hardware drivers, or higher-level software.

Exactly. And PulseAudio makes it a hair-raising experience to try and fix those problems.

Re:context aware?

[AdamWill]

Ironically, your message would make far more sense if it were talking about plain ALSA than about PA. ALSA is the configuration nightmare. PA makes it all a lot better.

generally speaking you should be able to configure just about everything you need to in pavucontrol. though it depends what version of PA you're working with, and how badly broken your distribution's implementation of it is.

Re:context aware?

[jipn4]

generally speaking you should be able to configure just about everything you need to in pavucontrol.

Yes, and that is the problem. I don't want to configure anything, I just want sound to come out of my speakers. I don't want to have to try out 2^40 different combinations of buttons and switches scattered over a dozen different tabs in order to make that happen.

Re:context aware?

[AdamWill]

"Yes, and that is the problem. I don't want to configure anything, I just want sound to come out of my speakers. I don't want to have to try out 2^40 different combinations of buttons and switches scattered over a dozen different tabs in order to make that happen."

And, let me get this straight, you thought things were _better_ with ALSA? Have you *looked* at alsamixer lately? Or, y'know, /etc/asound.conf , where you had to poke around to enable S/PDIF output? Or /etc/modprobe.conf , where you had to poke around to pick a default output device? The whole _point_ of PA is to present genuinely necessary configuration choices - like, y'know, whether you want analog or digital output, and which of multiple sound devices should be the default - in a very easy interface. Which was one of the major _failings_ of the previous situation.

(Given your post, it's ironic that one of the *other* major criticisms of PA is 'it doesn't let me tweak RidiculouslyObscureAlsaKnob Foo! It sucks!')

Re:Article is doomed to failure, but PulseAudio is

[AdamWill]

As I mentioned in an earlier comment, there are several distributions which are specifically designed to give you a good audio creation environment out of the box. Ubuntu Studio is probably the most well-known:

http://ubuntustudio.org/

but there are others. If you want to do audio production, you do not want to be using PA. You want to be using JACK. This may change in future, but that's the situation right now. Ubuntu Studio's documentation on getting going with JACK: https://help.ubuntu.com/community/UbuntuStudio/JackQuickStart

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Do I think pulse has a sane design? Yes I do for the most part, tho' I wont pretend to know it inside out.

The article you quote there (which was covered in /. before) has so many glaring errors I just don't know where to begin! If you're genuinely interested (and it sounds like you are), then I'd strongly recommend reading the comments on that thread, particularly the ones made by "dawhead" who I believe is actually Paul Davis who wrote Jack and Ardour and is about as much of an expert as you'd want on this stuff. He shows the patience of a saint in explaining (repeatedly) to the blog author where his analysis, opinions and criticisms are just plain wrong, providing very solid background as to why.

Paul is not a PulseAudio fanboi by any stretch of the imagination - he's clearly Mr Jack, but even he openly admits that some of the things going into pulseaudio are pretty smart. He doesn't believe it's necessarily the final ultimate solution, but certainly reckons that some parts of it could very well be used. With Linux it is all about evolution. Pulseaudio today is quite different to what it was a couple years ago, and I'm certain that it will continue to evolve and ensure that those good bits are matured and nurtured, and the missing bits are incubated.

The second or third last comment ("Executive Summary" on page 2 of the comments) also wraps things up nicely IMO.

JACK

[BrendaEM]

Should have went with JACK audio server.

Re:Article is doomed to failure, but PulseAudio is

[QuoteMstr]

The problem with PA's low latency set up is that it consumes and inordinate amount of CPU. Lennart has admitted that

[citation needed]

Worse than Ulrich Drepper?

[Grendel Drago]

Are they actually worse than Ulrich Drepper? Apparently the man writes some fine code, but wow is he difficult to get along with.

Re:Worse than Ulrich Drepper?

[Ant P.]

After reading Bug 4980, it makes me wonder. The only thing I could say in his defense is that he's a straight up asshole, as opposed to an egotistical one.

Re:Article is doomed to failure, but PulseAudio is

[petrus4]

Are you a PA developer, QuoteMstr? What exactly is your agenda, here?

Linux needs pro audio support.

[bollox4]

Is Linux capable of professional quality sound without glitching and problems? Absolutely! We already see Linux audio systems go hand in hand in the embeded market, and mobiles aside, even 100% rock solid pro gear like synthesisers. http://www.mvista.com/download/case_study_MontaVista_Linux_and_Yamaha.pdf Unfortunately for Linux until a reliable standard is settled upon that encourages the big boys to play, the Linux audio issues will continue. Who wants to assist a small market that cannot settle on a singular framework?

PulseAudio fails there too

[r00t]

By default, sound doesn't go everywhere. Given that quieting a device is much easier than searching for the obscure knob needed to make it go, this is an idiotic default.

What I really need is something like iptables and friends for sound. Yep, in the kernel, routing every which way. If I want to route the console beep out over VoIP, I should be able to just issue a few commands to set up audio routing and tunneling to do that.

A provisional apology

[petrus4]

Truthfully, I'm now wishing I hadn't been so profane in this thread. Some of the Pulse supporters who've spoken here, come across as being genuinely well-intentioned people; they just apparently haven't experienced the problems we have. Colin Guthrie primarily comes to mind here, which is why I haven't attacked him.

The other problem, I realise now, with coming in here and swearing and nerd raging my head off, is that it just leaves Pulse's advocates feeling even more justified and sure of themselves. Steveha responded with a fairly long post about how my original statement to him was subjective and entirely baseless, and what a child I was for engaging in so much profane ad hominem.

As I think someone else said though, what many of you don't realise is, that for the first half dozen to a dozen times, a lot of us genuinely do try to be civil.

The profanity only really kicks in due to extreme frustration, after we've tried so many times to explain the problem, and we're still just met with the same responses. Denial, bogus rationalisation, and various forms of ad hominem directed at us, simply because we're saying things which, because you want to think that everything is fine, you don't want to hear.

I don't really want to engage in profane or otherwise hateful behaviour, and I realise that I shouldn't. Being angry, aggressive, and hateful just ends up making me feel ashamed of myself later, and probably doesn't leave the people I behave that way towards, feeling terribly good themselves. All I really want is to see problems solved, and most of all for the culture of denial to be reformed; and that isn't happening.

The tendency of Linux developers to stick their fingers in their ears and yell, "la la la I can't hear you!" when they're confronted with unfavourable feedback, is not going to help them. The thing which primarily antagonised me about Steveha's original post is that it seemed as though he was telling people to just shut up and accept how gloriously awesome Pulse supposedly was, in the face of the number of reports in this very thread (and elsewhere) about the degree of problems that people genuinely are experiencing.

Re:A provisional apology

[Anonymous Coward]

The thing which primarily antagonised me about Steveha's original post is that it seemed as though he was telling people to just shut up and accept how gloriously awesome Pulse supposedly was

Steveha's original post:

how can we best proceed: by throwing out PulseAudio and starting over, or by fixing the remaining bugs in PulseAudio. I vote for fixing PulseAudio, and so has the rest of the Linux world, which is why PulseAudio is getting universally adopted.

The worst of the problems are over by now. To clean up the Linux audio mess, we have had to fix bugs in ALSA drivers, fix bugs in audio applications, fix bugs in PulseAudio, and get the distributions to setup PulseAudio correctly. It has been painful but we are well past the worst of it.

Where is the "shut up" part and where is the "gloriously awesome" part?

Re:Article is doomed to failure, but PulseAudio is

[BrentH]

I had a good read with those comments, didn't think of reading them before. It certainly sheds some light on why things are as they are right now. Too bad they're not really about Pulse, which may seem not so badly designed after all, still is not solving many problems we have. Apart from that it's implementation sucks still.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Do you care to elaborate on which parts of the implementation "sucks"? Is it the client/server model? The fact it uses a fully asynchronous, zero-copy, lock free core? Or something else?

I'd be interested to have a technical discussion about this, but obviously I'd need to more more than the equivalent of playground banter: "girls smell". :p

Re:Article is doomed to failure, but PulseAudio is

[mikerjohnson]

I'd like to thank you as well. I ended up hunting down your comments in this discussion. Very informative. I've been running Fedora 10 64 bit since its release with PA. I have had problems yes, but I can see how PA will solve some of the problems I've had in the past with Linux audio.

Re:Article is doomed to failure, but PulseAudio is

[tom17]

Thanks, i'll be trying that tonight.

Re:Article is doomed to failure, but PulseAudio is

[wertigon]

> Paul "Jack/Ardour" Davis summary is probably the best one I've read about why OSS is not sufficient

Link please? I'd like to read his arguments for myself and get my own opinion on things. :)

Re:Article is doomed to failure, but PulseAudio is

[AdamWill]

http://lwn.net/Articles/355542/

Re:Article is doomed to failure, but PulseAudio is

[BrentH]

I'm afraid I cannot provide you with that discussion (as I'm not even nearly technical enough to talk about it, would love to read such a discussion though). What I mean with 'sucks' is that I experience lag where ALSA doesn't and problems with using multiple programs (I admit the error may be in those programs not properly supporting Pulse) and sound just sometimes even drops when going to a few webpages with Flash for example (need to restart the system to fix that). I just appears very buggy and laggy to me, and judging from the chatter here and on forums etc I'm not alone in that.

Re:Article is doomed to failure, but PulseAudio is

[cynyr]

I just looked into setting up pulse on Gentoo, Arch, and LFS... It's a freeking nightmare. Nowhere is it mentioned what needs to be done to have 2 users on the same system have sounds played at the same time out of the same sink. It seems like you need to set the system-wide daemon up, but no "in event of a multi user desktop do foo". Why do i need to set up ALSA when i use pulse? ohh so apps that don't have pulse support can talk ALSA. and what about all of the problems with Wine and Pulse? To me the biggest advantage of pulse would be per app volume control. Now what would be even better is if i could say set up a reference sound to a min and max volume, and then never touch a volume slider again because the system would just normalize my audio for me.

So lets see hours of setting up pulse to get per volume sliders(and hoping it works with wine) or stick with ALSA and have everything "just work".... hard choice that one.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Well straight away, you're trying to do some kind of specialist setup, which is always going to mean you're going to have to look into things firther.

Also, PulseAudio is not something that is generally targeted at end users, it's targeted at distros who have the experience and knowledge to tie together all of the components.

You are also the first and only person who has complained that PulseAudio offers (for the most part) a drop in replacement for pure alsa via the use of an alsa plugin. This is *only* way that pulse could get any kind of acceptance at all. It's not expected that applications should need to write direct pulseaudio support, they should go through some kind of abstraction library. For the most part, libasound can serve that role well, provided you stick to the Safe ALSA API Subset that has been documented.

If all you want is per-app volume control, then I don't think it's all worth it for you, but if you want a proper multi-user desktop experience, where the sound follows the *active* user, not the inactive one (i.e. a standard desktop), reduced power consumption, bluetooth support, Apple Airtunes support, UPnP support etc. then PulseAudio is the way to go.

But free software is about choice. If it's not right for you, that's fine, don't use it, but there's no need to bitch about it either.

Re:Article is doomed to failure, but PulseAudio is

[cynyr]

multi headed/multi VT where both me and my wife have use of the same machine somewhat at the same time. to be fair, try getting plugging in of a flash drive to work on the same set up. I hear consolekit/policykit are susposted to help.

Really the only advantage i see of Pulse is the per app volume control. NAS (http://www.radscan.com/nas.html) and ESD (http://www.tux.org/~ricdude/EsounD.html) both provide the ability to pipe sound across the network. Now if Pulse could set that networked sound up based on SSH connections, and had a decent console app to change which sink to use (idk i haven't looked), it would be worth alot more to me. or if it had sinks and sources for macOSX/windows, i would be even more likely to set it up. think storage server hooked up the the stereo with a mac mini running boxee playing the content. Even better say i buy a N900, i should be able to advertise my server/desktop connected to the nice sound as a sink on the network, and have it show up, and be able to pulse that when you see this sink, make it the default.

There still should be documentation for this kind of a thing for distros. Not all of them are backed by for profit companies(or wealth individuals). Also most of my complaint is spending 3 hours tinkering with sound, to get it working again, with the very real chance that i may have to revert because a few of the apps i depend on don't work right.

Re:Article is doomed to failure, but PulseAudio is

[ShawnX]

Really? Your system sucks then because on mine it works fine! Have you submitted a backtrace for this issue? Even a bug report?

If you haven't then the bug doesn't exist, plain and simple.

I did, against *Buntu, I even used the PPA builds of PA, still crashed. I have the full crash dumps available on the bug: See: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/424551 This basically happened the same in Fedora also.

1) its CPU usage is reasonable

Well, on my system (4 year old core2duo) it sits between 0 and 1% even when playing...

Seems o be much higher on mu dual core2dual not even 1 year old.

Not heard of any problems here but is there a bug report about this?

3) It does not crash so much causing me no end of pain with multiple apps requiring audio.

I'm not experiencing any problems. It's been pretty stable for me for quite some time? What version have you been using?

Well, my typical use is like this: 1) KDE + audio, VirtualBox + audio, Second Life + audio.. PA keels over.

If you even had a tiny clue about things, you'd realise how ridiculous this statement is. OSS is old news. The API is not going to help us move forward. Have you even seen some of the stuff from the latest Linux Plumbers conference? Paul "Jack/Ardour" Davis summary is probably the best one I've read about why OSS is not sufficient and these are decisions that were made years ago... where on earth do people get this "OSSv4 causes world peace and solves every problem ever" option from? They've clearly never actually *looked* at things for themselves that's for sure.

Regardless, ALSA moves ever so slowly in the lack of resources. That's not to blame the developers at all. I've logged several bugs on this stupid Intel-HDA card and its PCM lack of capture. That wouldn't change with ALSA or OSSv4 if this is a hardware limitation.

We've had enough crap in the Linux Audio subsystem for so long, it's time to do the right thing and chunk the whole shit out.

Yeah because that kind of code writes itself right? All we need to do is get everyone to catch a fairy at the bottom of their garden and then stuff it into their CD drive... the code will be there by morning!

There are probably about four people working on linux sound as a paid job... Lennart, Takashi, Jaroslav and Paul... Maybe a few other too, but typically in very specific disciplines/hardware, but certainly none of them are going to start working on OSS that's for sure. So where is this magical work going to come from?

People have to write it...

I'll accept more pain if we get it right, finally.

This is us getting it right and this is that pain.

You might be, but, I remain unconvinced for now. My sense of PA is the dumbed down interface and lack of functionality that is missing. It's bad enough the microphone on this intel-HDA doesn't work properly by me having to adjust _3_ properties in order for someone to hear me and even then its either too loud or too soft. I don't see how PA will fix this problem.

Re:Article is doomed to failure, but PulseAudio is

[colin_s_guthrie]

Yes consolekit is the bit to work on when dealing with multi-seat systems. Udev and consolekit very recently were changed to support seats a little better but there is more work needed in that area. Pulseaudio already integrates to consolekit, so using this system is the way to go.

In the mean time, if you have tow sounds cards (e.g. one for each of you) you can do a "poor mans" setup but each logging in once, and then being nice ot the other but loading pavucontrol and choosing the "Off" profile for the card not meant for you. This doesn't work if you swap seats tho', but for this kind of setup, I'm guessing that doesn't happen too often anyway. Like I say support in consolekit is coming.

NAS and ESD are both obsolete, so are no longer developed and should not be used.

PulseAudio does not have it's own SSH piggy back implementation like X11 but we do piggy back on to the X11 one. Really openssh needs to be refactored to make the X11 forwarding modular and we can then write a PulseAudio module for SSH so that it can all be done properly.

OSX support is also underway but it's done by those people who are interested and only two people are really interested right now, so the progress is a little slow, but getting there.

The routing policy you describe (when you see it, use it) is now implemented in PA git master with module-device-manager, although currently only a KDE gui for this is available (it's not the way Gnome want to work, but it is the way KDE want to work, so I accommodated that).

And the disto I do packaging for is certainly not backed by a wealthy individual. It just takes someone who actually cares to get the distro integration right, not money :)