×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PulseAudio Creator Responds To Critics

kdawson posted more than 4 years ago | from the louder-please dept.

Linux 815

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

815 comments

This is the Sound of (5, Funny)

Anonymous Coward | more than 4 years ago | (#29791259)

Firrrrrsssst P Po Po sssst

Re:This is the Sound of (1)

stonefoz (901011) | more than 4 years ago | (#29791293)

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 (5, Funny)

Anonymous Coward | more than 4 years ago | (#29791543)

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

who's to blame. (5, Insightful)

delirium of disorder (701392) | more than 4 years ago | (#29791261)

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. (0, Troll)

DNS-and-BIND (461968) | more than 4 years ago | (#29791317)

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. (5, Insightful)

Anonymous Coward | more than 4 years ago | (#29791333)

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. (2, Insightful)

GameMaster (148118) | more than 4 years ago | (#29791435)

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. (2, Informative)

ta bu shi da yu (687699) | more than 4 years ago | (#29791741)

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. (5, Insightful)

xtracto (837672) | more than 4 years ago | (#29791445)

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. (1)

donaldm (919619) | more than 4 years ago | (#29791657)

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. (4, Insightful)

Jason Pollock (45537) | more than 4 years ago | (#29791481)

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. (1)

UPi (137083) | more than 4 years ago | (#29791533)

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. (3, Insightful)

phantomcircuit (938963) | more than 4 years ago | (#29791689)

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. (1)

noundi (1044080) | more than 4 years ago | (#29791745)

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. (0)

Anonymous Coward | more than 4 years ago | (#29791841)

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

Useless (5, Insightful)

Carewolf (581105) | more than 4 years ago | (#29791269)

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 (5, Informative)

Cyberax (705495) | more than 4 years ago | (#29791287)

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 (5, Insightful)

Anonymous Coward | more than 4 years ago | (#29791319)

...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 (4, Insightful)

Per Wigren (5315) | more than 4 years ago | (#29791411)

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 (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29791471)

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

Re:Useless (0)

Anonymous Coward | more than 4 years ago | (#29791645)

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

Re:Useless (1)

IBBoard (1128019) | more than 4 years ago | (#29791813)

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 (3, Insightful)

J Story (30227) | more than 4 years ago | (#29791359)

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 (1)

Cyberax (705495) | more than 4 years ago | (#29791389)

Yeah, sure.

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

Well, thought so.

floating point works fine in my kernel (2, Interesting)

r00t (33219) | more than 4 years ago | (#29791649)

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 (1)

Cyberax (705495) | more than 4 years ago | (#29791699)

"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 (1)

Vanders (110092) | more than 4 years ago | (#29791787)

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 (4, Informative)

r00t (33219) | more than 4 years ago | (#29791851)

"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:Useless (4, Insightful)

Richard_at_work (517087) | more than 4 years ago | (#29791681)

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 (2, Insightful)

Cyberax (705495) | more than 4 years ago | (#29791827)

"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 (3, Interesting)

Anonymous Coward | more than 4 years ago | (#29791399)

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

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 (3, Funny)

Anonymous Coward | more than 4 years ago | (#29791337)

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 (0)

Anonymous Coward | more than 4 years ago | (#29791609)

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 (3, Insightful)

Ant P. (974313) | more than 4 years ago | (#29791349)

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 (3, Informative)

setagllib (753300) | more than 4 years ago | (#29791451)

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 (4, Informative)

mickwd (196449) | more than 4 years ago | (#29791595)

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 [pulseaudio.org]
*
* 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."

Among other distros, Ubuntu... (4, Interesting)

jonaskoelker (922170) | more than 4 years ago | (#29791365)

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:Useless (0)

Anonymous Coward | more than 4 years ago | (#29791563)

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 (2, Informative)

shadowknot (853491) | more than 4 years ago | (#29791673)

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.

Durability in the face of errors (5, Insightful)

ZorbaTHut (126196) | more than 4 years ago | (#29791275)

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 (1)

L4t3r4lu5 (1216702) | more than 4 years ago | (#29791327)

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

Re:Durability in the face of errors (1)

DangerFace (1315417) | more than 4 years ago | (#29791789)

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 (5, Interesting)

abigsmurf (919188) | more than 4 years ago | (#29791683)

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 (0)

Anonymous Coward | more than 4 years ago | (#29791821)

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.

The problem isn't the idea (3, Insightful)

amorsen (7485) | more than 4 years ago | (#29791279)

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 (1)

pembo13 (770295) | more than 4 years ago | (#29791353)

> bugs are being ignored.

That's a blatant exaggeration

Re:The problem isn't the idea (0)

Anonymous Coward | more than 4 years ago | (#29791513)

> 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 (0)

Anonymous Coward | more than 4 years ago | (#29791775)

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 (0)

Anonymous Coward | more than 4 years ago | (#29791667)

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.

Why do I care where the bugs are? (4, Insightful)

jonaskoelker (922170) | more than 4 years ago | (#29791305)

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? (-1, Flamebait)

pembo13 (770295) | more than 4 years ago | (#29791343)

No one said you had to care, this is one of the devs explaining the issue, and obviously he cares. He never implied that you should care.

Why is OSS no longer in the kernel? (2, Interesting)

Valdrax (32670) | more than 4 years ago | (#29791335)

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? (5, Informative)

Ant P. (974313) | more than 4 years ago | (#29791407)

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 [4front-tech.com] 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? (5, Insightful)

LizardKing (5245) | more than 4 years ago | (#29791495)

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.

4Front's interpretation IS relevant (0)

Anonymous Coward | more than 4 years ago | (#29791591)

"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

Re:Why is OSS no longer in the kernel? (1)

InEnacWeTrust (1638615) | more than 4 years ago | (#29791581)

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 [4front-tech.com] 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? (2, Funny)

DangerFace (1315417) | more than 4 years ago | (#29791831)

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? (0)

Anonymous Coward | more than 4 years ago | (#29791449)

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.

My bug reports were ignored! (1)

HRbnjR (12398) | more than 4 years ago | (#29791367)

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 [redhat.com] and was totally ignored.

Or not... (2, Informative)

bradley13 (1118935) | more than 4 years ago | (#29791517)

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... (1)

cheekyboy (598084) | more than 4 years ago | (#29791651)

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.

Or yes (1, Flamebait)

HRbnjR (12398) | more than 4 years ago | (#29791665)

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.

The year of... (0)

Anonymous Coward | more than 4 years ago | (#29791369)

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

Too many choices.... (4, Insightful)

Max Romantschuk (132276) | more than 4 years ago | (#29791393)

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.... (4, Informative)

Anonymous Coward | more than 4 years ago | (#29791671)

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.... (1)

complete loony (663508) | more than 4 years ago | (#29791767)

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.

Creeping featuritis (1)

ponos (122721) | more than 4 years ago | (#29791425)

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.

It may be buggy... (1)

AlgorithMan (937244) | more than 4 years ago | (#29791453)

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... (4, Insightful)

batkiwi (137781) | more than 4 years ago | (#29791569)

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... (0, Offtopic)

dwater (72834) | more than 4 years ago | (#29791847)

> the other two major OSs have

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

Distribution problem (5, Informative)

LS (57954) | more than 4 years ago | (#29791455)

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 [ubuntuforums.org]

LS

Yes, it cannot be pulse audio's fault, because: (2, Insightful)

Anonymous Coward | more than 4 years ago | (#29791469)

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? (5, Funny)

WWWWolf (2428) | more than 4 years ago | (#29791509)

I disagree with the original article [blogspot.com]: 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? (0)

Anonymous Coward | more than 4 years ago | (#29791555)

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

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

Jeremy Visser (1205626) | more than 4 years ago | (#29791777)

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

Way not to get the point: why users are angry (5, Insightful)

Idaho (12907) | more than 4 years ago | (#29791519)

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.

PulseAudio is overhyped (1)

jonaskoelker (922170) | more than 4 years ago | (#29791703)

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 [slashdot.org]

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

10 years ago, sound DID work reliably in Linux (4, Informative)

r00t (33219) | more than 4 years ago | (#29791731)

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.

Could you get sound from multiple sources? (5, Informative)

Sycraft-fu (314770) | more than 4 years ago | (#29791833)

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.

realtime (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29791545)

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.

Pulseaudio works for me better than ALSA or jack (0)

Anonymous Coward | more than 4 years ago | (#29791551)

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! (5, Insightful)

Beelzebud (1361137) | more than 4 years ago | (#29791573)

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! (4, Insightful)

abigsmurf (919188) | more than 4 years ago | (#29791725)

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

Article is doomed to failure, but PulseAudio isn't (3, Informative)

colin_s_guthrie (929758) | more than 4 years ago | (#29791627)

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/ [guthr.ie]
and
http://thread.gmane.org/gmane.comp.kde.amarok.devel/15356 [gmane.org]

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 no way to get lipsync! If the audio output device is network based (bluetooth headphones etc.) the time delay from audio pumped into the buffer to when it's heard can be much increased and this needs to be handled gracefully!). On embedded systems and laptops, power consumption is very important which is one of the reasons why there is so much interest in PA from the likes of Intel and Nokia just now. Now, I admit that this mechanism did uncover many problems in the alsa driver layer. These problems have largely been resolved now, but many people seem to project these issues as pulseaudio problems which is unfair. For more information on latency see http://pulseaudio.org/wiki/LatencyControl [pulseaudio.org] and for more information about the timer based scheduling see here http://0pointer.de/blog/projects/pulse-glitch-free.html [0pointer.de] I strongly recommend you read both.

Then of course there is the mixer. Everyone knows the ALSA mixer controls are insane. They make no sense to almost everyone and vary wildly from hardware to hardware. Pulseaudio does a very good job at rationalising this and while it's impossible to get this 100% right, it's coping admirably just now, while pushing for sanity upstream in ALSA. PulseAudio development really has pushed the ALSA development, both in terms of the kernel-level drivers (see previous paragraph) and the userspace API.

Then there is the whole concept of thin-clients. This is where native PA netowrk support goes beyond the "toy" label I gave it above. In this scenario it's rather important. Right now if I ssh to another machine on my network and run Amarok there, I hear the sound on my local speakers. This works by piggy backing connection and athentication information into the X11 root window which is SSH knows how to forward. Arguably this is not ideal as it needs a direct network return path and open ports etc. The correct solution is to abstract the X11 forwarding foo in ssh and implement a PA forwarding option too. This will come in time. I've written a bit about how this kind of thing works here:
http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ [guthr.ie]

As for those who have had poor experience with PA, I have to say that a lot of this criticism is due in no small part to the distros. I package for Mandriva and I care about user experience and made sure that when we adopted PA several release ago that I configured and setup the vast majority of audio applications to work OOTB with PA just fine. I also ensured that it is very easy to turn PA off if you don't want it. This seems to be something I've seen people complain about recently: "I have to use PA because my distro breaks if I remove it!". Well, you shouldn't remove it (due to linked library problems) but there is absolutely no reason why you cannot disable it. If you can't, then this is a distro problem pure and simple. Complain to your distro or switch to one that does it properly. The power is yours.

Now I don't like to get involved distro wars, but Ubuntu has had a very poor track record with PA. They introduced it in an LTS release with very little though or due care and attention. This has harmed opinion of PA considerably. Ubuntu has gotten much better since then, the people involved are engaging with us upstream and a really good people to work with, but first impressions are hard to shake. I hope all the Ubuntu users and especially the Kubuntu users (I don't think phonon or kde runtime was patched in Kubuntu like I did to make it work sensibly, albeit with a crippled UI if (and only if!) the user is using PA, but correct me if I'm wrong) who formed their opinions of PA back then will give PA a second chance on a well integrated setup.

So while many people may have had bad experience of PA, it doesn't mean the idea or architecture are flawed. You've probably being using a distro that doesn't care to integrate PA properly or are in the unfortunate case that your ALSA drivers have not been tested properly with the bits of the API that pulseaudio exploits. If PA didn't expose this, some other ALSA client would, so stop crying about it and fix the problem where it lies.

And one final statement, many users have pointed out that the applications causing PA to crash. Of course that is not acceptable. Never should an app be able to crash PA, but if an app is doing things incorrectly it should be fixed. These two things are mutually exclusive so please don't read anything into comments that suggest that crashing bugs should be fixed in the applications doing the crashing and not in PA itself. We fix crashing bugs whenever we come across them, for example the new Skype beta exposed an assertion that should have been handled differently which we duely patched and backported to the stable branch within a day or two of being notified *and* helped the Skype developers fix their problem too. That is what is meant by fixing the applications. It does not mean that crashing bugs are ignored.

works great here, but... (1)

neaorin (982388) | more than 4 years ago | (#29791633)

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.

Ubuntu is ruining Pulseaudio's reputation (4, Informative)

Per Wigren (5315) | more than 4 years ago | (#29791663)

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 [0pointer.de] today.

People like Lennart should die an horrible death! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29791685)

Lennart Poettering is an arrogant idiot! Pulseaudio is bloated to death.

A legend in its own mind (5, Insightful)

Devlin-du-GEnie (512506) | more than 4 years ago | (#29791721)

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.

bad user tools for pulseaudio (1)

GNUPublicLicense (1242094) | more than 4 years ago | (#29791751)

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 (4, Informative)

Deanalator (806515) | more than 4 years ago | (#29791753)

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! (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29791755)

It's not just for Windows anymore!

My take on PA (1)

amn108 (1231606) | more than 4 years ago | (#29791769)

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 (1)

MoeDrippins (769977) | more than 4 years ago | (#29791795)

> 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 (3, Interesting)

petrus4 (213815) | more than 4 years ago | (#29791799)

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 [catb.org], 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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...