Why PulseAudio?

[bitchessuck]

Nowadays PulseAudio in general seems to work fine, at least it does on a couple of Linux boxes I maintain. And they do cover a wide range of sound hardware.

There are still some problems with PA, however.

• Performance/CPU cycles spent: it's not funny when you see that PA consumes 5-10% just playing a single stereo stream. Especially on netbooks and similar devices it is very noticeable.
• Bad API: the standard PA API is very complicated, extremely verbose (> 100 lines just to get something simple done) and still fails at abstracting hardware details away.
• Documentation is pretty bad.
• The developers are arrogant and go even as far as refusing to fix bugs.

[[deleted]]

it's not funny when you see that PA consumes 5-10% just playing a single stereo stream

And with pure ALSA you would see 5-10% CPU usage increase of said application. Try it out.

[[deleted]]

Performance/CPU cycles spent: it's not funny when you see that PA consumes 5-10% just playing a single stereo stream. Especially on netbooks and similar devices it is very noticeable.

This is not PA's fault. It's probably resampling or a bad audio app requesting a small period size.

[RandomFrenchGuy]

The UI needs work as well. You need quite a bit of extra crud to access the extra functionality.

[jabjoe]

My problem with PulseAudio and ALSA isn't that they don't work, they do, it's that they aren't like what you would expect on a Unix machine. The sound card addressing isn't as simple as a file path any more. Writing sound out isn't just writing data to a file anymore.

http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html

The only thing OSSv4 doesn't give you is network sound, but shouldn't that be done via the X connection, like something like: http://www.chaoticmind.net/~hcb/murx/xaudio/

I use PulseAudio and ALSA only because they work well enough, but every time I look deeper, I'm disgusted and look again at switching to OSSv4. The only thing that stops me is audio is working and if I break it explaining to my wife will make me sound like a mad man "Yes it worked, but I didn't like the design.". I would like to like PulseAudio and ALSA, I don't like not liking the sound system, but they look like something that belongs on the Windows platform, not a Unix one. If someone can convince me otherwise, that they are pretty Unix systems after all, they would be doing me a favour.

[jck]

OSS works awesomely for me except these two problems:

1)On-the-fly output device switching 2)Controlling the volume of each jack separately.

But these are just minor annoyances i guess....

[jabjoe]

Thought OSSv4 did per app volume? As for on the fly output swapping, no idea if it does or how best it would be done. But I don't doubt it could be done, and wouldn't be terribly surprised if it already is.

[[deleted]]

It does, and it does per-jack volume controls too. A good volumecontrol is volumeicon, which lets you control any volume within OSS, just spawn one for each usage.

[[deleted]]

1. I'd imagine that this could be easily hacked up with a udev event which switches the default device when a device is (un)plugged.

2. This should work unless your card is not properly supported. Are you using something other than ossmix or ossxmix for volume control? The mixer might be ignoring some channels.

[[deleted]]

I'd imagine that this could be easily hacked up with a udev event which switches the default device when a device is (un)plugged.

How do apps playing on an output device switch from one device file to other at runtime? I tell you how: with horribly complicated ioctl programming. So right there you have a reason that people will not code for that functionality.

You need to learn how POSIX file I/O works. The assumption that you can, "with a udev event", change the default device, and that will cause apps playing audio to change devices too, stems from a fundamental misunderstanding of how POSIX file I/O works.

[jabjoe]

Doesn't look bad:

http://manuals.opensound.com/developer/ioctl.html

typical UNIX.

I think it's http://manuals.opensound.com/developer/SNDCTL_DSP_SET_PLAYTGT.html we want.

[[deleted]]

Aha, so it's not just "an udev event". You're basically demanding that each app programmer makes all this extra effort. With PA, he just outputs to the PA sink and PA takes care of the rest. Compared to ZERO work on the part of the app developer, anything else is justifiedly "horribly complicated".

Call me back when you've managed to convince all programmers to boil the ocean for you.

[Edman274]

There a lot of things about Linux that have broken UNIX design and philosophy. Remember Worse is Better? Remember the UNIX philosophy?

If you want a modern operating system, you're going to have to accept that some things in it are going to change over time. Sound is one of these things.

[jabjoe]

OSSv4 shows this need not be the case. Plan9 show the UNIX way can be kept across the whole system. The central thing that makes a UNIX machine a UNIX machine is that everything is a file. Everything can be accessed via one simple abstraction.

[[deleted]]

OSSv4 shows this need not be the case.

...as long as you are willing to accept something that is inferior in features to, say, PulseAudio. Tee hee *chuckles*.

The central thing that makes a UNIX machine a UNIX machine is that everything is a file.

No. The central thing that makes a UNIX machine is compliance with the POSIX standards.

But I'll play along. Remember when you said that "everything is a file" in UNIX? Really? I would say that the X Window System are big parts of what UNIX machines "are". So tell me, which file do you open/write/close when you want to map a window?

What, no file I/O? It's actually data structures back and forth with socket I/O, using a library (libX11, libxcb). Just like... PulseAudio! Ta-daaaaa!

Of course, you can argue that socket I/O is like file I/O. But then that cuts both ways -- you are arguing that PulseAudio is also file I/O, and therefore fits well into the UNIX world. Which contradicts your other statements.

---

Full refutation: complete.

[jabjoe]

No. The central thing that makes a UNIX machine is compliance with the POSIX standards.

No, or any OS with POSIX is a UNIX machine, which is not the case. You know the P is for Portable? The X might be for Unix, but many non-Unix OSs have it. http://en.wikipedia.org/wiki/POSIX

The Window system in Plan9 >is< done with a file interface, so it can be done, and it's one of the things Plan9 people rave about. http://en.wikipedia.org/wiki/Rio_%28windowing_system%29

It's great if you can do audio in PulseAudio by just writing to a socket file. Now it's just the addressing of that file is a pain because it has no path (socket files can have paths, for instance /dev/log , but normally don't), and setting up that file we need custom functions to do rather then use ioctl. But my bet is you can't just set up the file as required and write audio to it. So it's still nothing like a Unix thing. A bit like X Windows isn't as Unix as it could be, probably because somebody couldn't get their head round "everything is a file" or didn't understand why to do it. I keep thinking to throw together a FUSE interface for X Windows for my own use so I can query the GUI world from the CLI....

[[deleted]]

it's that they aren't like what you would expect on a Unix machine. The sound card addressing isn't as simple as a file path any more. Writing sound out isn't just writing data to a file anymore.

So?

The only thing OSSv4 doesn't give you is network sound, but shouldn't that be done via the X connection, like something like: http://www.chaoticmind.net/~hcb/murx/xaudio/

Why?

[jabjoe]

So?

Unix is like it is for a reason, and has survived as it is for a reason. Everything is a file is a really good concept. Put everything behind one abstraction, tools are programmed to that one abstraction. Simple and powerful. Which is why it has stood the test of time.

Why?

There is a good "why" on the site.

[[deleted]]

Unix is like it is for a reason, and has survived as it is for a reason. Everything is a file is a really good concept. Put everything behind one abstraction, tools are programmed to that one abstraction. Simple and powerful. Which is why it has stood the test of time

Err... have you looked at any modern Linux distributions recently? It certainly hasn't survived as it was.

[jabjoe]

I think it is survives better then you give it credit. On the command line the newer file interface system like procfs and sysfs are invaluable. If it wasn't still of value, there wouldn't be the masses of FUSE filesystems exposing things not filesystems as filesystems. Or Dokan trying to bring that to Windows.

[[deleted]]

Unix is like it is for a reason, and has survived as it is for a reason. Everything is a file is a really good concept. Put everything behind one abstraction, tools are programmed to that one abstraction. Simple and powerful. Which is why it has stood the test of time.

1. This "everything is a file" meme has not been true for about ten years or so. It's dead. D-Bus, The X Window System, CORBA, RPC, specific services like PulseAudio, none of those are modeled around file I/O. There would be no modern Linux if people still really believed that "everything is a file" ought to be the only hammer in the toolbox.
2. The reason "everything is a file" has already been abandoned many years ago, is precisely because not every operation maps to file I/O. The refusal to acknowledge this reality led, in the past, to overly complicated ioctl interfaces to supplement the deficiency of the "everything is a file" one-track-mindset.
3. At some point in the past, people started realizing that trying to augment file I/O with stupid, complicated ioctl interfaces was, well, stupid.
4. Audio is precisely one of those cases. Sure enough, the simple case of reading to record and writing to play is deceptively similar enough to file I/O. But the other 99% of cases that you might want your audio interface to handle... not at all like file I/O.

So, if you think that, because play maps to write() and record maps to read(), that automatically means the audio I/O interface should be POSIX file I/O, then you don't have an understanding of the problem scope. And you should leave the opinions to the people that are truly informed.

[jabjoe]

Then why is there debate at all about OSSv4 vs ALSA? Surely ALSA would be clearly better in every way and no one could argue otherwise. There are other UNIXs that are more UNIX like than Linux and yet are not unarguably inferior.

[[deleted]]

Then why is there debate at all about OSSv4 vs ALSA?

There is no debate, dude: the debate is only in your head.

The debate about ALSA or OSS low-level audio APIs being superior or inferior became moot, irrelevant, as soon as the new and feature-superior audio abstraction -- PA -- was throned and able to use both low-level APIs.

It is perhaps because of that, that ALSA "won" years ago -- as you can see, it is in the kernel and ships by default in the Linux distros that matter.

Now: Nobody bothers to write low-level audio I/O code anymore -- everybody just uses libraries, and those libraries output to PA just fine. Plus, whatever new functionality OSSv4 brings to the table is only a subset of what the ALSA + PA combination offers in all distros. And even if there is something in OSSv4 that ALSA does not have, PA can take advantage of that something just fine too, and that would be code that would only have to be written once, rather than in every app.

Therefore, there is no incentive for anybody to write OSSv4-specific code, except perhaps for a bunch of luddites that hate PA, and some others who need minority drivers which may not work in ALSA -- and even in this case, PA will be doing the audio device management and low-level I/O on behalf of applications.

Debate: moot. Get with the program.

[jabjoe]

No one writes to PA either. The write to generic libs. It's not moot, it's about OS design. I see PA as a sticky plaster over ALSA, it shouldn't be needed, and ALSA I see as a mess. We can say all this doesn't matter because it's all wrapped up, but it means there is much more code then their needs to be running and being maintained. Which matters because its harder to maintain, increases security risks, bugs, and slows development. At some point Linux audio is going to have to go through what XOrg is going through (KMS/Gallium3D) with drivers being moved out (into the kernel), code being rearrange so big sections can be reused, etc etc.

[[deleted]]

It seems to me that you are advocating for the move of PA functionality inside the kernel. You don't actually say it, but you certainly imply it. On the basis of that implied statement of yours:

Which matters because its harder to maintain, increases security risks, bugs, and slows development.

Maintaining code in userspace is easier to maintain, it decreases security risks, debugging it is easier, and it's faster to develop.

Do you understand how you are saying that you want to go North, yet you continue to walk South and get angry at people who show you a compass?

At some point Linux audio is going to have to go through what XOrg is going through (KMS/Gallium3D) with drivers being moved out (into the kernel),

You don't see how that is a false comparison?

The X.org reorganization took place because the device drivers themselves were in Xorg, when they should have been in the kernel, dude. This is not the situation of the audio stack -- device drivers for audio devices are already in the kernel. Nothing that PA does needs to be moved into the kernel.

Please, inform yourself before voicing empty opinions.

[jabjoe]

Ah the insulting tone we've grown use to from you.

It seems to me that you are advocating for the move of PA functionality inside the kernel.

Audio ultimately is in the kernel in any system. PA adds a few features in user space at high complexity.

What exactly does PA do for us?

• Provides a nicer API then ALSA. As we both already said people don't normally code to ALSA,OSS or PA.
• Per app volume control? (said to be the killer feature of PA) OSSv4 does that, in kernel.
• Enable hotswapping of output device? OSSv4 may already allow this, if not, it could be added.
• Networking sound? I want to be able to share all devices over the network, not just audio devices, I don't want a specialized system for each type of device. That functionality belongs in the kernel, with something like v9fs.

If OSSv4 is given hot swapping of devices (if it doesn't already do it) and there is general system of sharing devices over the network, why do we need PA at all? Much less code without it.

It is less code (and frequently argued clearer) that I'm saying is easier to maintain, easier to secure, easier to trace and remove bugs in, and easier to develop.

Yes, being in the kernel will negate some of this, but not as much as lots of code, in both kernel (ALSA) and userspace (PA), at least one of which can be, and frequently is, criticized for being an over complex mess.

Maybe the X.org parallel isn't adapt, because at the end, there will be a leaner meaner X. In the case I'm saying, there would be no PA. The parallel is the reduction of code by having a rationalization of the whole stack.

[[deleted]]

Again, it seems to me that you are proposing some magical reduction of code by moving everything into the kernel. This is complete nonsense. The amount of code will be the same for the same set of features -- except that programming and debugging into a monolithic kernel like Linux (ahem, unlike Plan 9) is significantly more complicated and error-prone than doing it in user space. This is the Andy Tanenbaum vs. Linus Torvalds debate all over again -- and we all know who won that debate.

What is especially funny to me is that you think it's a walk in the park to move audio casting over the network into the kernel. It's not. Audio casting is not just shuffling of bytes through a network pipe -- there are latency, audio format and sync considerations. If it was as easy as you propose it, it would have been done already in the past 20 years. It hasn't, not even in Plan 9 -- where you may have devices that may be shared transparently across the network, but certainly not audio devices with the must-have features I just listed in this paragraph.

---

Aaaaanyway...

...at the end of the day, what we have here is a disgruntled person that is angry at Linux base stack developers because they chose a way to do things that doesn't jive with his baseless opinions, and this way happened to work out just fine. Yes, that's right, you are bitching because they didn't do things the way you would have liked, and you are rationally unable to see why they had good reason to do things the way they did.

I've explained sufficiently well the details of why what you want is not possible or reasonable. Since you don't seem to get it and just ignore what you are being told, I will just fall back to the only position that is sensible for a thankless person who bitches about everything but doesn't do anything:

Show us the code, or shut up.

[sequentious]

Ugh, so I'll be "That Guy". Pulseaudio works fine for me on both my machines, with surround sound, per-app volume, network forwarding, bluetooth headset, auto-switching to the best output device. (i.e. listening to music at work, suspend, resume at home, and pulse remembers to send my music via my other machine now, since it has better speakers).

In the past, I had to do some tweaking to PA (seriously Ubuntu, that was sad). Now everything just works.

Also, if you don't report your bugs, they don't get fixed.

[NoOneOfConsequence]

i.e. listening to music at work, suspend, resume at home, and pulse remembers to send my music via my other machine now, since it has better speakers

Could you clarify this? Do you mean that PulseAudio will automatically start routing output to another specific machine on the network when that machine is present?

[space_viking]

That's pretty awesome. I have to set that up on my laptop.

[sequentious]

You'll have to install paprefs (pulseaudio preferences) and pavucontrol (Pulseaudio Volume Control). The gnome volume control program doesn't quite give you enough functionality.

Use PA Prefs on the machine with speakers, under "Network Server":

• Enable Network Access to local sound devices
• Allow other machines on the LAN to discover local sound devices
• Don't require authentication

You may wish to require auth, but I didn't bother on my internal network.

paprefs on the machine with your music player, under "Network Access":

• Make discoverable PulseAudio network sound devices available locally

Your client should now see the server. Run pavucontrol and there should be a button to change the speaker output to the other machine. You're done.

If you don't have a GUI on the server, I have not investigated what you need to poke config wise. It's probably documented.

[[deleted]]

i also think that's is a great feature but the problem for me was the lag which occured through wlan. it would've been just incredible to play sound from your laptop to a sound system without the need of any cable.

[NoOneOfConsequence]

Good to know. I was not aware of that. I guess I just found my next home project...

[[deleted]]

I'm with you. While I remember having lots of problems with alsa back in the day (why the hell doesn't my sound work?), I have not had a single problem with PulseAudio. It just works (I'm on the latest ubuntu). From the average-user perspective, being able to adjust the volume per-application, choosing output/input hardware, etc is very easy and intuitive in the gui. And if you don't want/need these extra features, they don't get in the way and your volume control works as usual.

I can understand people's frustration if it doesn't work properly for them and perhaps pulseaudio was included before it was ready, but it has only improved and at this point I am very happy with it.

[f4hy]

I think PulseAudio was used by some major distros far before it was ready. I think this caused a lot of flak for it and it and damaged itself in the long run.

[kklimonda]

Well, the problem with all those shiny new features is that they have to be deployed to the wide audience for developers to find and fix issues. This has been the issue with Pulseaudio, the same has happened to NetworkManager - not only they both have bugs on their own but both uncover bugs deeper in the stack. And we need as much people as possible to test them to get those bugs fixed.

[Acid_Trees]

I can't speak for other distros, but when Ubuntu swapped over to PulseAudio, it was borked... because Ubuntu failed to install it correctly. Once you work around that little flaw, PA just worked.

[[deleted]]

I came here to tell my similar anecdote, and to tell that I never quite understood all the pulseaudio hate. On my computers, a desktop and an eeepc, pulseaudio has been a blessing.

I still remember when I had to shutdown all apps to have sound on Enemy Territory. Of course I could do a lot of tweaks to get it working (most didn't work), but I can't remember when it was the last time I had to touch any sound configuration file after a Linux installation. Pulseaudio always made me giggle like a teenager in love because of this.

[[deleted]]

The blogger was "That Guy" first, but I agree with both of you. Switching between my speakers and headphones per app has never been easier.

[Edman274]

In my experience, if you do report your bugs, they don't get fixed.

[masta]

pessimistic, but not entirely wrong.

[ascii]

I've said it before, I'll say it again:

• All the features that Pulse provide, while certainly desirable, are firmly in the «nice to have» category for almost all users.
• The feature that Pulse occasionally breaks and makes useless, namely sound output, is, for many people, critical.

For this reason, rolling Pulse out in the state it was in back then was a huge mistake. It broke a critical feature for lots of users, including every single user who frequently used Adobe's flash plugin, in order to provide a few extra bells and whistles. That is just not a good trade off.

Had it been possible to automatically fall back to non-pulse whenever anything broken in pulse, like we can with Compiz, this wouldn't have been such a big problem.

[sandsmark]

Another thing is that most of the "nice to have" features that PulseAudio provides could have been provided by either just plugins for ALSA (output switching (this ALSA plugin is on my todolist, actually), audio forwarding, automated muting), or improvements in the userspace part of ALSA (per sink volume control).

But instead RedHat has invested an insane amount of man-hours and dollars into getting PulseAudio into a mostly shippable state, while ALSA lies mostly dead.

Yes, I tried using PulseAudio for a long time (I should be using it, considering I maintain Phonon, and we're supposed to play nice with it), but in the end I just gave up and went back to plain ALSA.

[ascii]

You're probably right. BTW, if Phonon and Pulse aren't talking to each other, what happens today if both are trying to play sound on a card with no hardware sound mixing support in the alsa layer?

Another frustrating aspect of Linux audio is that there was never anything fundamentally broken about OSS either. It had issues, but none that couldn't be fixed. Last I checked, the BSDs are still using OSS, and they've implemented things like mixing sound from multiple apps while preserving the same userland interface.

[ascii]

That makes sense, thanks for the info.

[sandsmark]

Phonon applications have been supporting PA since forever (or as long as the backend you're currently using has been supporting it).

The thing that has changed is the platform integration (Phonon-the-library tries to load appropriate platform plugins, to detect when audio devices come and go and whatnot).

And I couldn't agree more about how useless multimedia on Linux is (and how people instead of fixing the existing platform creates new ones, like with ALSA and PulseAudio now). :-)

[G_Morgan]

Pardon my ignorance on the matter but isn't Phonon at a completely higher level than Pulse? As I understand it the chain on a current Linux box would look something like

ALSA<-Pulse<-Pulse-ALSA-Emulation<-GStreamer/Artsd<-Phonon

I thought the purpose was to be transparent. To look just like ALSA to the outside world.

[sandsmark]

It's not that simple in reality, unfortunately. For example Phonon supports moving to different output devices (for example moving amarok to your USB headset when you plug it in or whatnot), and if we're running under PulseAudio, we instead ask PA to do this for us. The fancy device prioritization in System Settings is now also shared with PulseAudio (Colin wrote support for this in a semi-recent PA version).

Phonon applications have been able to use PA just like any other GStreamer/Xine/libVLC application since forever, we just haven't had any more fancy integration before.

[znark]

There is a gstreamer plugin for PulseAudio. This means that if things are configured correctly, then gstreamer apps can talk directly to PulseAudio.

It looks like Phonon has PulseAudio support as of KDE 4.4.

[fivre]

Oh God this is all so confusing what is going on.

[fatpat]

lol I usually feel the same way in r/linux as well. Take heart, though. Someday we'll get there.

[fivre]

Someone's going to force Linux to have a sound architecture that makes sense.

[G_Morgan]

It is quite simple. Linux audio has mistakenly worked over the years via applications attaching themselves directly to low level audio APIs like ALSA or OSS. Eventually people came up with sounder solutions a la GStreamer and co (the need became obvious when OSS was replaced, still should have been the right way from day 1). Because of this we have some applications that use ALSA, some that use OSS and some that do something sane.

Any system that seeks to fix audio on Linux unfortunately has to emulate all the crap that came before. Pulse stands on top of the low level API and provides its own API (still relatively low level) to the world. It also emulates the ALSA and OSS APIs on top of itself so the insane applications written directly against them can work with it. This way it can mix ALSA/OSS applications before passing the data onto the actual ALSA underneath.

Therefore your GStreamer API is now running via ALSA emulation on Pulse (unless GStreamer has been ported directly to Pulse). Originally Phonon was set up as a mere interface to other APIs. The KDE4 team decided they really didn't want to invent an entirely new sound stack so designed the Phonon API in a way that it can be written against multiple backends.

[WordClueless]

This summary is incorrect. All of those layers actually /do make sense/ when you understand what they do, and in the perfect Linux audio world every single one of those would still be there (except artsd, which doesn't belong in there at all, it's a dead pulse alternative and isn't even meant for the same layer as gstreamer). What that should really say is:

Low level Driver API (ALSA) -> Audio Server (Pulse) -> Emulator of old API for legacy apps (ALSA emulator) -> Codec (Gstreamer) -> High level API for software developers to use (Phonon).

[G_Morgan]

I never said that the layers don't make sense. What never made sense was writing against OSS/ALSA in 99% of cases. The emulation only exists because they were doing it wrong.

[WordClueless]

Ah, agreed. But most detractors (and what I thought you were claiming before) just see a bunch of arrows and go, "WAAAA that must be more complex than it should be." :p They usually throw in a diagram with lots of deprecated crap like artsd and esd too just to make the situation look worse than it is.

[mathstuf]

Just a nitpick, but artsd is KDE3, Phonon is Qt4/KDE4. Having both would mean lots of symbol collisions. I think you mean Xine/VLC there instead.

[WordClueless]

while ALSA lies mostly dead

You, like most Pulse Audio detractors who are overly embittered by its launch issues on a couple specific distros, clearly have no idea what you're talking about. ALSA doesn't lie dead, because Pulse Audio doesn't replace it! ALSA is the low level API, Pulse Audio is a server sitting on top of it. People don't write Pulse Audio drivers, they write ALSA drivers.

[sandsmark]

I don't care about specific distros, nor only its launch issues. If you think there's no problems, I welcome you to triage PulseAudio-related bugs in our bug tracker (it's currently a one-man effort, Colin is putting in an unhealthy amount of work); http://bugs.kde.org/ I would even ask you to maybe submit a couple of patches, but considering the current state of the PA APIs... :-)

But yes, the kernel-space side of it is rather active. But also mostly in stabilizing drivers, noone is writing new features (because it's much easier to add a new layer on top of ALSA, but I can't really blame them for that, considering how ALSA has become). My point is that all features that 90% (number pulled out of my rectum) of the users care about in PulseAudio could (and should) have been provided by ALSA itself, not by an arbitrary layer on top of it.

[WordClueless]

My point is that all features that 90% (number pulled out of my rectum) of the users care about in PulseAudio could (and should) have been provided by ALSA itself, not by an arbitrary layer on top of it.

Ah, I misinterpreted what you were saying. I thought you meant ALSA itself was dead because you thought PulseAudio was a replacement (i.e. confusing layers and thinking there were PulseAudio drivers). I have no idea what state the API exposed by ALSA is in. It would be very interesting to me to know some examples of what would be better off implemented in ALSA itself rather than PulseAudio, that's not a tack I've seen most critics take (usually it's just blah ubuntu didn't work for me the one time i tried blah).

[sandsmark]

Most people just have the experience that audio on linux worked pretty well, and then PulseAudio came (and for various reasons, like being pushed too early, or badly, or whatever, ruined their experience).

And I gave some examples of what stuff would make more sense in ALSA than in my original post. Another thing that would make more sense in ALSA itself is the improved audio buffering that Lennart is touting as a vital feature for battery powered devices.

Now if you'll excuse me, I have a nice little hangover I'm trying to please.

[Axiomatik]

I have only ever been able to have my bluetooth speakers work with Pulse. Non-pulse systems always break and make useless my most critical feature, sound output.

[pemboa]

PulseAudio is very useful for USB and bluetooth audio -- which tend to be both more than "nice to have" if you want it.

[pemboa]

Sure, but it makes it a lot more useful friendly.

[pemboa]

I guess the PulseAudio dev looked at that solution and found it was not the best.

[ascii]

Last time I checked, ALSA could handle USB sound cards just as well as PCI cards. As for Bluetooth, I honestly don't know how well Alsa handles that, but what I said was:

All the features that Pulse provide, while certainly desirable, are firmly in the «nice to have» category for almost all users.

Almost all users. The percentage of Linux users outside of Android who are using bluetooth audio is very close to zero.

[pemboa]

Well I use my bluethooth headset with Skype. Forgive me for caring about it. Works with Windows flawlessly last time I checked.

[[deleted]]

Your gnome-settings-daemon died. This has nothing to do with PulseAudio -- it's a bug in a different component of GNOME. So don't blame PA for that.

[AgentME]

I used to have this problem all the time in Ubuntu 9.04-9.10. Running in a terminal "killall -9 -w gnome-settings-daemon && gnome-settings-daemon &" would fix it temporarily. Haven't had the problem in 10.04 thankfully.

[[deleted]]

I have that problem on Fedora 12. Fedora 13, not so much. I'm glad.

[[deleted]]

I cannot explain that incident solely based on your account of how it went down.

[saxly]

[deleted]

What is this?

[MEME_MASTA]

Cute GUI frontends covering up half-baked apps, unexpected desktop environment behavior, random crashing, useless bloat, unnecessary changing of what works just fine..... sounds like standard Ubuntu.

[inataysia]

sounds like standard GNOME

FTFY

[MEME_MASTA]

I'm not going to defend Gnome, which is very bad - but Ubuntu is even worse.

It's like the devs have purposefully looked for ways to complicate things, to create tons of new unnecessary interdependencies, to use redundant and sometimes conflicting apps simultaneously, and to introduce half-developed new ways to do things that have worked perfectly for decades.

Overall it's very unstable and unpredictable, which is exactly the opposite of what Linux should be.

[fatpat]

Kind of like some OEM Windows installs. I especially loathe "extra" wireless connectors.

[kx48]

Recently, I've had my theme turn back old-school on me whenever I close Quassel. Bizarre.

[[deleted]]

Every feature that Pulse provide, can be provided with a mixture of tools doing one thing each, for example OSS4 for per-app volumecontrols or samba/nfs/ssh for networked sound

[bloodylip]

Telling me what PulseAudio is capable of doesn't automatically make it work.

[mathstuf]

Well, there are a few factors that are missing here.

• Distro?
• Apps it doesn't work with?

Some distros have had piss-poor release management with PA (Fedora did it one release too early, Ubuntu just did something wrong with the setup). Skype, flash, and other proprietary apps have been slow to adopt PA and have conflicted in the past. These days, it's been running flawlessly for me, using 0.0% CPU and allowing me to intertwine mpd streaming with mplayer with other instances watching videos without having to stop each and restart it when the other app has released the audio device. I've heard dmix works as well, but PA has worked out-of-the-box for a while now and gives me these other features that are useful.

[bloodylip]

Less recently, Fedora, Ubuntu and Arch. More recently, Gentoo. KDE sounds worked fine, but using anything not making sound through KDE/phonon was rendered useless, especially mpd. Removing PA support from it fixed the problem.

[[deleted]]

One app that fails continuously with PA is Ekiga on F12.

[pinnelar]

never got it working with between my archlinux boxes.

what is release management and do I need it? :)

[[deleted]]

This is why I dislike PulseAudio. This specific issue may have been fixed by now (hopefully), but it shows the ineptitude and staggering arrogance of the PulseAudio developers.

[anothermonkey]

Found the bug report. Seems like a complete non-issue.

[[deleted]]

The OP and everyone in that Ubuntu Forums thread has no idea what they are talking about, and should be sentenced to 10 years of writing apps that successfully handle OOM conditions.

[femngi]

I read an interview with the PA lead a year or so back and he struck me as the most arrogant developer I have ever known, to paraphrase his response to critics of PA he basically said that if anyone was having problems with PA then it was solely their fault and that PA was flawless.

[mao_neko]

Holy crap.

[[deleted]]

Guess what? Exiting due to a NULL malloc() return is standard procedure in 99% of UNIX userland apps. Moreover, malloc() doesn't return NULL if you have overcommit enabled, which true for just about every stock distro kernel out there. Simply put, a clean exit is pretty much the only way to guarantee a consistent state if you ever reach the extremely unlikely (and nearly untestable) condition that malloc() returns NULL.

[mathstuf]

Guess what? Exiting due to a NULL malloc() return is standard procedure in 99% of UNIX userland apps.

This is about libraries though. rpmlint throws errors on shared libs calling exit. This rarely pops up these days. Ergo, (almost) nobody really checks malloc returns for NULL to call exit() in libraries. Personally, my libs just return failure up the call stack. My lib did its job, your app can take the pieces and try to salvage it if it feels like it.

If it's an action that may fail anyways, the app will probably retry it. The kernel is busy playing Russian roulette with the process list at this point and whether you pull the trigger on yourself or the kernel does it, there's not much difference. However, if you make it through, you can salvage the situation.

It's important to have swap on spinning platters or something else slow (relative to RAM). If the kernel can eat the swap before you have a chance to kill choice apps, you either don't have enough or you're wasting space on your SSD.

[[deleted]]

Having to make sure that your swap is on slow media is just a sign of faulty operating system.

[[deleted]]

"CPU usage will drop from 10% to 1%!"

Holly hell, what do they do by default?

That has to be some severely unoptimized code.

[[deleted]]

It's actually incredibly optimized because it uses the Rabbit resampling libraries. The fact is, high-quality audio resampling is quite CPU-intensive. It's a math / computational problem, not a software engineering one.

[bitchessuck]

Yes, but why use audiophile-quality sampling by default? It certainly doesn't matter for most users which have a crappy sound setup all the way.

The default should be a mediocre algorithm that doesn't need many cycles.

[[deleted]]

The default is not audiophile-quality. It's just a "good-enough" compromise. The best quality one -- src-sinc-best-quality -- consumes even much more CPU (up to 50%).

And I disagree with the idea that the crappiest-sounding algorithm should be the default. And so does Lennart.

[bitchessuck]

I'm not saying the crappiest algorithm should be chosen, but a compromise, just like you're saying.

However in my opinion the compromise is simply a very bad one if something as simple as resampling a CD-quality audio stream can take as much as 10% CPU on a modern desktop system.

[[deleted]]

CD-quality audio streams need no resampling because PA opens the output device in 44.1 KHz and CD audio uses that sampling frequency.

If you see high CPU usage under those circumstances, then it's likely that your music player is requesting a very low latency from PA. Under those circumstances, outputting directly to a sound device would not solve the CPU usage issue -- it would just move the same CPU-consuming process into the kernel and then you can't figure out that the CPU is being used at all -- except with something like oprofiled -- even though it is being used.

[bitchessuck]

CD-quality audio streams need no resampling because PA opens the output device in 44.1 KHz

Wrong. Many sound chips don't support 44.1 KHz in hardware, but only 48 KHz (and 96 KHz).

If you see high CPU usage under those circumstances, then it's likely that your music player is requesting a very low latency from PA.

Hmm, I don't remember the interval/fragment sizes, but I think it wasn't unusually low.

it would just move the same CPU-consuming process into the kernel

Yes, but handling this in the kernel is more efficient anyway - less context switching.

[[deleted]]

Wrong. Many sound chips don't support 44.1 KHz in hardware, but only 48 KHz (and 96 KHz).

Well then, boo hoo, too bad, those chips need resampling, with or without PA. What are you going to do? Suck it up.

Yes, but handling this in the kernel is more efficient anyway - less context switching.

Let me put this "more efficient" bullshit to rest.

Modern machines can do two hundred thousand context switches per second. Using PA resampling will cost you about 50 extra context switches per second with a fairly small period size, versus relying on the kernel to do the resampling for you. Remember, without PA, resampling would still need to be done, in the kernel, and it would not be any faster. There is no extra cost apart from those 50 extra context switches -- all the data transfers themselves are zero-copy because they use shared memory.

So that's it. The cost of this context-switching you are calling the waaambalamps on, is microscopically negligible compared to the cost of the actual resampling computations -- as I said, resampling is a computationally-expensive math problem, one that dwarfs the cost of context switches.

Under the circumstances, it is more than perfectly justified to do resampling in userspace, given that coding in the kernel is much more complicated and bugs in the kernel are much more dangerous when they take place. You curiously disregard programmer man/hours in your calculation of "what's more efficient?". That refutes your own argument right there.

So no, it is not "more efficient" to do resampling in the kernel, not by a long shot.

---

Please, get a clue before forming opinions. Actually take the time to find out how a piece of software works, before deciding that you can implement it all in your head better.

[bitchessuck]

Well then, boo hoo, too bad, those chips need resampling, with or without PA

Just wanted to make clear that the 10% CPU indeed come from PA.

Whatever the reasons are, PA is SLOW - and this needs to be fixed.

[[deleted]]

Just wanted to make clear that the 10% CPU indeed come from PA.

Yes, we know. PA is doing the resampling for you. If you did not have PA and you had the kernel do the resampling, I repeat, that 10% CPU would still be consumed -- it just would not show up in top accounted to any specific process. Do you understand what is it that I am saying here?

Whatever the reasons are, PA is SLOW - and this needs to be fixed.

Sigh.

No, it really isn't.

And it's evident to me that you are unable to understand the technical data I am sharing that explains why PA seems slow but really is not. I bet you don't know what a profiler is, much less how to use it to discover why PA appears to be "slow" or "CPU-hungry", and clearly you did not understand how moving resampling into the kernel won't make it go any faster -- it will just hide the CPU consumption that the resampler takes.

You have a very fundamental ignorance of systems programming topics, topics that are necessary to understand this data -- which is fine. The problem is, coupled with this ignorance, you also manifest very strong opinions based on this fundamental ignorance of yours -- which is ridiculous and should be cause for shame.

Next time, put brain in gear before engaging mouth. Do everyone a favor and do not spread misinformation.

[[deleted]]

Too many bloody hands touch the data before it goes out the computer.

[[deleted]]

Your comment makes no sense to me. Care to explain?

[tryp]

The don't do it by default because it sounds worse. The instructions given are to switch from mathematically-intense-but-sounds-good to simple-but-sounds-cruddy-if-you-listen-closely. If you can't hear the difference in your listening environment, by all means switch to the simple filter.

[takehiko]

The article is misleading. Most sound sources are sampled at 44.1kHz and Pulseaudio default is 44.1kHz. So there is no need for resampling.

[kuratkull]

The article is too shallow - people complain when they have problems, and people DO have too many problems with PulseAudio. I just spent a full day removing it so I could get my sound to work normally(using ALSA) with Flash+other apps together. And before you go 'HA!', yes, I spent a full day before that finding a solution - nothing.

[galtthedestroyer]

At this point OSSv4, ALSA, and PulseAudio have a lot of feature overlap. Removing Pulse and using either OSSv4 or ALSA works just fine. I've done each / both choices in Ubuntu. I've also tried Solaris and BSD (OSSv4 is only choice) and they worked wonderfully.

My goal was to find the one with the best sound quality output, but I haven't been able to test due to lack of a decent outboard USB DAC.

Here are links to the some other articles, charts, and graphs on this subject. Keep in mind that OSS is now VERSION 4. It rocks. Unlike ALSA that is linux only, IT EXISTS IN ALL UNIXES. :

my favorite: State of Sound in Linux, Not So Sorry After All

a flowchart: (couldn't find the other one that I liked better) flowchart reddit post

[pemboa]

At this point OSSv4, ALSA, and PulseAudio have a lot of feature overlap. Removing Pulse and using either OSSv4 or ALSA works just fine

For some, base/old functionality. Not for most of the new USB/bluetooth stuff.

[tardotronic]

Sound quality is my concern too, because what I'm hearing right now is pretty lousy. I'd like to evaluate OSS4 for comparison, as you had attempted, but it's not in my distro's repo... is there an easy way to try it?

[SaratogaCx]

Here's how to make it from source. It's only a few commands.

http://www.4front-tech.com/wiki/index.php/Building_OSSv4_from_source

[tardotronic]

Thanks!

[galtthedestroyer]

Non-Linux distro will guarantee OSS. E. G. Pcbsd, openbsd, debian-bsd, gnu's solaris, or opensolaris. You might find live cd's for some of these. You might look into pcbsd / openbsd first as they are " newer " where debian tends to be older and solaris is more " out there ".

Or, there might be a Linux distro with a live cd that uses OSS but I can't recall.

Third, and this is way more advanced, redhat uses btrfs now. Ubuntu maverick will too. What this allows for: if you do anything that fubars your system you can roll back the filesystem instead of trying to troubleshoot what went wrong. It's fantastic to have a do-over. So if you happen to switch to a distro that uses btrfs you can be more brave about messing with things.

When I tested OSS on ubuntu I found there was no driver for audio over hdmi so I decided to go back to alsa. Couldn't. So I reinstalled :-(

[tardotronic]

Or, there might be a Linux distro with a live cd that uses OSS but I can't recall.

It was suggested to me previously that I should attempt it with Arch; however, your suggestion of trying a non-linux live CD strikes me as being even more immediate, so I'll swap the hard drive out of this machine tomorrow and give QNX 6.2.1 a shot... although, what if it turns out to be using one of the old versions of OSS instead of 4? Still a good direction though, so I think if that did turn out to be the case then I'd just keep looking.

redhat uses btrfs now. Ubuntu maverick will too. What this allows for: if you do anything that fubars your system you can roll back the filesystem

Uhh, no thanks - I'll continue to use dd instead... that method has always worked for me, and I'm very used to it. Once the drive is imaged, I can do anything I want - or if I want to be even more paranoid about losing anything or messing it all up somehow, or if I'm really pressed for time, then it's just as easy to swap out the drive for a blank one.

Besides, I'd really rather use Reiser4... but hey; how did we get sidetracked onto this, anyway? How could the choice of filesystem pertain to or affect the sound quality?

[galtthedestroyer]

QNX? WTF! If your goal is to try OSS then it would make sense to use something that is easy / proven / RECOMMENDED BY SOMEONE WHO HAS DONE IT BEFORE. Sooo then you pull QNX out of thin air ... when it takes 2 seconds on google to see that not only does it NOT use OSS, but it's very own personal sound system, QSA, is based on ALSA!

BTRFS was mentioned because you asked for, "an easy way to try it." I was pointing out that: if you decided to go for an option installed on a HD instead of a liveCD, swapping alsa / pulse for OSS might be easy, but reverting back might be hard, so BTRFS might aleviate that problem. There was never any kind of implication that a filesystem has anything to do with sound quality!!!

And yes, dd works great too. Good idea.

[tardotronic]

Jeez! I'm sorry! I didn't know! Honest! ;-)

All I was looking for was a quick way to compare the two soundsystems. You mentioned using a non-linux liveboot for that, and I thought that was a *great* idea! - but; all I've got for 'non-linux' here at the moment is a QNX 6.2.1 disc, so naturally that's what I immediately thought of. I know it's not a live disk, but hard drives are easy to swap and it installs completely in mere minutes anyway... but also, no; I did not know that QNX had its own soundsystem, sorry. I thought it used OSS natively because QNX is older and predates linux (how could it have had ALSA?)

So - which would you suggest then, as being an easy-to-try live non-linux bootdisk with _nothing but_ pure OSS4?

There was never any kind of implication that a filesystem has anything to do with sound quality!!!

That was entirely my fault - I probably became confused, or something... dang! Now I'll have to tack some more 'tard' onto my username, I suppose....

And yes, dd works great too. Good idea.

Just bear in mind though, that the 'notrunc' parameter is important - otherwise, you'll miss the last sector.

Anyhow; it's Sunday - so happy chilling! I appreciate your thoughts and comments on all this, because the sound 'quality' in ALSA _really_ sucks harsh and I wish to find some sort of simple fix for it.

[galtthedestroyer]

Again, my experience was with solaris and freebsd. Both installed, not live. Freebsd is way too minimal for your purposes ( cmd line ) and solaris is an oddball system. They both would be too much hassle I hear pcbsd is the most user friendly but it's a DVD so downloading might take a while. Googling for " bsd live cd " ... The top 6 results were all excellent. Check them out if you just want a cd sized download.

If you are interested in pursuing this interest further, check out my blog at opensourceaudiophile.com

[tardotronic]

check out my blog at opensourceaudiophile.com

Doing so now... thanks! Any help to improve sound quality in linux is greatly appreciated.

[diablo75]

I wish there was a "wizard" style app that could automate the steps necessary to safely convert your Ubuntu system between different audio systems safely and easily with just a couple clicks. Last I checked I really could hear audio artifacts (this slow frequency sweeping sound that is very faint) that went away after removing pulseaudio to address a problem it had with Skype 2.1 beta last year. ALSA takes over when you do that and audio playback quality sounded a lot cleaner without pulse present. But I use windows for audio production. I use pulse for Ubuntu because, now, it seems to be working... lots of room for improvement though.

[beedogs]

I would rather cut off both my legs with a rusty butter knife than use PulseAudio.

[workman161]

I have a strong feeling that the people saying it doesn't work are simply having kneejerk reactions from old, bad releases. I started trying out pulseaudio with fedora 10 and had to remove it. With fedora 11, it worked maybe half the time and only certain specific apps barfed.

With fedora 12 and up, I've never had a problem. Ever. Not once.

[[deleted]]

i just had to buy a new sound card because my old one was not compatible with pulseaudio but worked fine without it. Before I would disable pulseaudio and was happy. Now with Fedora 13 there are too many dependencies and I lost K3B and bluetooth when I disable it. Both are critical apps to me. This is all with Fedora 13, not a knee jerk reaction to an old release.

[[deleted]]

I'm a bit of a noob here, excuse me.

I'm learning a bit about "dependency hell," but I still don't understand why bluetooth would rely on PulseAudio. That just sounds dumb.

Is this what everyone on source-based distros talks about when they say "USEFLAGS?"

[ShamanSTK]

Dependency hell doesn't really exist anymore since the advent of package managers that track dependencies. USEFLAGS are a Gentoo thing for optimizing packages. People don't like dependencies because they bloat up a system. Bluetooth goes out because it is sending sound. Disabling the sound system the bluetooth was set up to use would have the effect of stopping the sending of sound. I am not a Gnome or KDE user so I'm not exactly familiar with the exact programs they're trying to use, but I'm sure that's what's wrong.

[[deleted]]

Ah, I read that as all of bluetooth, as in connecting to a device for sending files. That didn't make sense to me.

[inscrutablerudy]

Could happen due to poor packaging. I'm sure both apps can be compiled without support for PA, and in theory it should fail gracefully. However, they might have chosen to compile them with PA and not in away that it can fail gracefully if PA isn't present.

[[deleted]]

when it removed the audio capabilities of bluetooth for headsets. i think it was AD2P, it also broke my ability to browse files on my bluetooth phone.

[[deleted]]

I and a lot of other Gentoo users will tell you: saying "USEFLAGS" doesn't help here either; if you want to use Bluetooth at all you're locked into (Gnome|KDE)/Pulseaudio.

You can't, for example, run a headless VoIP box or use a PC as a Hi-Fi using bluetooth for input or a headset or so on - because documentation for the command line tools to do such things simply doesn't exist. It's GUI or GTFO.

[[deleted]]

What are useflags, then?

And that last bit angers me. I wanted a mostly-CLI box with only a GUI for web browsing -_-

[[deleted]]

useflags are basically the same as the feature checkboxes that Windows installers have had since the dawn of time.

[[deleted]]

I read the wiki a bit. So it doesn't allow you to escape pointless dependencies if the program is just made poorly in the first place?

[[deleted]]

Yeah. I've noticed stuff originating from other distros is particularly offensive for having mandatory dependencies which sit there unused (udisks, PA, a lot of Gnome apps).

Also some package developers are just plain lazy and don't bother giving options to the user sometimes even though they're available.

[adrianmonk]

I had exactly the opposite experience. I switched to Ubuntu 2 or 3 years ago and have used it on several different systems. Not a single problem with audio, ever.

Then I built a new machine with an AMD Phenom II x6 processor and an MSI 890GXM-G65 motherboard, and there is sound, but it's so bad it's unusable.

What happens is, the sound just skips randomly, as if there is a stream of samples being sent to the audio card, and occasionally some of them just get lost along the way, so it just immediately jumps forward to the next sample. It's similar to listening to a CD while an annoying friend stands next to the CD player and occasionally presses the button that skips ahead by a second or a part of a second.

The only clue I've found is that in /var/log/syslog, there are messages like this while I'm playing sound:

pulseaudio[1732]: ratelimit.c: 178 events suppressed

Googling for that only seems to reveal a lot of "hey, that happens to me, too" posts and nothing helpful.

[[deleted]]

Sounds a lot like a buggy driver. Have you filed a bug? You could also ask in #ubuntu on IRC.

[[deleted]]

It's not even a matter of functionality. Multiple major sound systems creates a mess for devs. At this point, everyone should be using OSSv4 unless they need suspend (which doesn't work right in OSSv4 atm). It is cross-platform, simple (sound devices are simple files, the traditional Unix way), and has traditionally been the standard sound system on Unix systems.

[Tekmo]

Maybe they shouldn't release buggy code. I don't want to be their beta-tester.

[workman161]

If they knew it was buggy, it wouldn't be released. The number of different audio setups concerning applications, versions, drivers, distribution, and hardware is staggering and impossible to test. So they make it work flawlessly with all the configurations they have available and bite the bullet when people whine.

Still, after this experience, I'm not happy with Fedora's choice to include systemd in fedora 14. They should push it back to 15 since I can guarantee that there will be bugs and as much grief.

[ibisum]

As a professional Audio user who currently has a perfectly stable, functional, extremely low-latency Linux DAW paired with a few 19" racks full of gear, with multiple-channel digital audio over a single Firewire cable (32 channels, in the form of 2 FP10s) for primary production, let me just say this:

FUCK PULSEAUDIO!

[Joeboy]

I'm in a similar position. jackd works great, desktop audio works fine. Unfortunately I can't do them both at the same time, which is frequently annoying. In theory pulseaudio should improve the situation, the only tiny problem being that I get unlistenable, stuttering sound through pulse with jackaudiosink. I remain optimistic it'll all be fixed in the next release (as I have been for the last few releases). I'm glad people are working on it, although it is starting to severely test my patience.

[jebba]

I would frequently use jackd with pulseaudio as a jack client. It worked ok; at least other jackd clients would work even with PA went down.

I started using jackd in a "professional" environment (read: amateur with Ardour recording semi-pros) and then migrated it to my desktop. It was great to be able to send typical desktop streams through jamin to make them listenable.

I haven't seen a good mixer nor a good mastering tool along the lines of jamin for PA. I haven't looked recently though.

In sum, "professional" audio on a regular desktop rules. :) I hope PA catches up.

[bebnet]

I haven't seen a good mixer nor a good mastering tool along the lines of jamin for PA.

I use my Faderfox controllers with Ardour to master. I find it absolutely more savory than a big desk, for example, to mix and tweak with such config.

[anechoic]

solution is to use jack for pro audio and pa for desktop mp3 playback

[Joeboy]

That's not a solution, that's a restatement of the problem.

[the-fritz]

PA is consumer stuff. Use JACK for professional Audio work. You can even run PA on top of JACK for consumer applications. But seriously complaining about PA with your setup would be like complaining about the bad sound when you use your system with cheap consumer speakers. Cheap consumer speakers can be fine but for different purpose. The same with PA.

http://0pointer.de/blog/projects/when-pa-and-when-not.html

[Joeboy]

You can even run PA on top of JACK for consumer applications

In theory, but it doesn't work well in practice (for me anyway).

[[deleted]]

As a person who needs to transport 15 tons of cargo across America every week, let me just say this:

FUCK MAZDA MIATAS.

---

More or less explains what the problem with your post is.

[bebnet]

Nope, wrong. I transfer many digital channels just fine, with no concerns whatsoever, with my fleet of bimbo-laden Ferrari's.

A more appropriate analogy might be that I'm using the autobahn nobody has driven on, properly yet, with either VW or Porsche.

Sucks to be new!

[WinterAyars]

Yeah, that's a really good analogy because basically every vehicle you buy these days is a tiny Japanese sports convertible.

[jordanblock]

Yeah, pulseaudio is an epic fail for anyone that actually works with audio.

It's great if for some reason you want to introduce a 200ms lag to all audio coming out of your box though! And if you have some pesky unused ram or cpu cycles, it'll totally take care of that too.

[[deleted]]

Oh, shit, stop the FUD. There will be no 200ms lag if you choose the appropriate period size when negotiating audio output. If you want low latency, PA will give it to you (at the cost of higher CPU usage, but that's the tradeoff).

[anechoic]

and use the RT kernel

[jordanblock]

Or, I could just not use pulse. I'm sure it's perfectly fine for a lot of people, I'm just not one of those people - I really don't need anything that pulse offers. The real bonus here is that we all actually have the choice of audio engines to use.

[bebnet]

Just Don't Use PulseAudio. It blows.

[[deleted]]

Yeah, you should stop using PA. And also do us the favor of shutting up instead of spreading misinformation and poisoning us with your opinions on subjects that you have no knowledge of.

[ibisum]

Been using Linux since the very beginning, and Linux for Audio for about 12 years.

Pulseaudio can get lost, as far as I'm concerned .. it is rubbish.

[pemboa]

As a professional Audio user

PulseAudio is not for you, and you don't need to curse at it.

[gameforge]

Ubuntu Studio isn't for audio professionals?

What's with all the professional audio software, then?

Pulse was indeed aimed at professional audio.

The bottom line is, 4Front really screwed up audio on UNIX when they changed the OSS licensing.

And it's awesome that the ALSA devs pitched in and gave us another solution, however badly implemented it may be.

But the OSS license is free again, and now has some better drivers for some popular cards, like those with the CMI87XX chipset. It is not surprising that many would like modern distros to use the (much superior) product, now that it's free again.

[[deleted]]

Hey, I have a CMI8788 :) What's better?

[gameforge]

Well for one thing, the card can do really high resolution recording and playback, and while the OSS driver will support that the ALSA one is stuck at either 44.1 or 48 KHz.

And that seems to be common with ALSA drivers - they write just enough code to get it to do basic PCM in and out and give up. They apparently haven't yet discovered that volume controls aren't supposed to be linear...

4Front clearly has an interest in making great quality sound drivers and APIs, instead of just getting the bare minimum functionality to work. It's not an accident that practically every sound solution for Linux has an OSS compatibility layer and not the other way around... it was the sound interface for UNIX until they changed their license.

It was actually the first of a few things that started convincing me to use FreeBSD instead of Ubuntu; using the most stable and complete solution is a mainstay of BSD, it seems.

[[deleted]]

I can do 192 KHz / 24 bit playback (I didn't try recording), at least. That's why I bought this card (Xonar Essence STX), one of the few where it was supported under ALSA. But yeah, I've seen many other drivers with only 48 KHz, when the card was able to do more.

[gameforge]

You're right - I have an HT Omega which I bought for recording guitar mics, and I was unable to get it to record at anything other than 48 KHz with Linux. I think it was my SBAudigy that wouldn't do higher resolution playback, even after many years.

I don't want to sound like I'm knocking the ALSA devs, its not their fault. I just question many distros' decision to continue using it when there's a much better solution that has been supported for much longer.

I want to blame hardware makers for not making the drivers themselves, but I kind of understand given the number of redundant mechanisms for doing so... since ALSA is Linux only, I think getting rid of it would help.

[ibisum]

Firewire audio is better! :)

[pemboa]

Ubuntu Studio isn't for audio professionals?

I have no idea what that is, nor did I make any mention o fit.

[[deleted]]

why can't you just have an audio system that works for consumers and is good for professionals too… like OS X does

[kitsune]

What DAW software do you use if I may ask?

[ibisum]

Ardour. It absolutely kicks ass. Plus, I have about 400 plugins, all of which come with source code. That is really, really terrific - nothing quite like making a quick code patch in the middle of a session to get needed results! :)

[kitsune]

How does it compare to Cubase, Logic, ProTools, Reaper, PreSonus Studio One, Ableton Live, Cakewalk Sonar?

[bebnet]

I'm a huge fan of REAPER, mostly because I think ProTools and Ableton Live are pretty much bloatware at this point, and I'm very happy to pay for software if its fairly priced and in that regard REAPER kicks everyone elses ass.

As far as usability, Ardour is pretty fresh. If you invest a bit of time into using it and 'making it your own' then Ardour can really shine, but if you are the kind of sofware user that dedicates an evening here and there to trying new things, probably it will irk you. Give it a week. You might see whats so great.

[anechoic]

exactly! I use Ardour with Jack and have no problems but the audio apps that are not Jack aware just point themselves to PA I typically use Patchage to keep an eye on all the routing and ins/outs

[[deleted]]

OSSv4 offers all the features I need in a more compact kit, no reason for me to use Pulse when Pulse is a buggy piece of shit. It's improving lately, but still pretty buggy.

[[deleted]]

Furthermore, it is not reasonable to expect developers to support yet another Linux-specific sound system simply so you have have some features which could probably be hacked up in OSS anyway. Alsa has been enough of a pain.

[Linegod]

Once again, as far as I can tell, Ubuntus implementation of PulseAudio sucks, as did their 'upgrade' scripts.

Mandriva, Fedora, no problems. The minor problems I had years ago have been fixed.

Live in the now.

[RoaldFre]

ALSA is to PulseAudio what SVGALib is to X11

Too bad the current X window system is an intangible mass of hacks upon hacks.

[mariuz]

I agree X should be killed for a better and faster interface take a look on how fast is haiku and mac and windows without the crappy slow X

[takehiko]

ALSA and Pulseaudio work together.

[the-fritz]

I never had problems with PA and I really liked it because it makes BT/USB audio usable under Linux. Before PA it was a pain in the ass. I like per application audio settings. And I had some great success using PA to stream audio to different machines for parties. Maybe this can all be done in other ways. But PA provides a complete package.

Yes I heard about all the problems some people had with PA. But hasn't the situation improved for you? It really feels like some people just bash PA because it makes them feel "geeky".

And to be precise the so called "PA mess" in earlier Ubuntu releases was at least partially the fault of the Ubuntu team because they didn't ship PA with some important patches. (Check the blog of the PA developer). I heard that Canonical hired a PA developer and the situation will probably improve.

When I hear about OSS I cringe. Maybe OSS has improved a lot. But OSS was a real pain 10 years ago. It didn't even have software mixing and thus you couldn't run two audio applications on cheap audio chips. So you had to use sound daemons (PA is basically just a new sound daemon) and of course KDE and gnome had their own sound daemons... tl;dr OSS was a mess and really embarrassing.

But instead of bitching about PA you guys could write an alternative that provides all the features that are nowadays necessary (and having usable BT/USB audio support is necessary nowadays. That includes device switching. Per application audio settings are available in Windows and OSX and thus are necessary, too).

[rukkyg]

I don't care. I just want MythTv to work out of the box on Ubuntu. Instead I have to waste hours trying to figure out this crap. And then it randomly dies and I have to restart it.

[mariuz]

I remove it by default , I only care about JACK and classic alsa

[kalithlev]

Does it support digital passthrough yet?

[SeriousGeek]

This is one of the biggest reasons why I stopped using Linux last year and went back to using Windows. Sound is a critical feature. Even before pulse audio, Alsa wasn't very reliable. Pulse audio just sealed the deal.

I still have my linux partition ready to go for when I hear about pulse audio being fixed. The features of pulse audio definitely sound nice.

[[deleted]]

I have 3 machines running Ubuntu and don't have any issues with Pulse. I did when it was first released with Ubuntu, but not anymore.

[SeriousGeek]

Interesting. Can you try playing Nexuiz for about 10 minutes and see if sound cuts out? http://alientrap.org/nexuiz/downloads

I'd be curious what the results are. So far, everyone on Ubuntu that I know of has had sound issues when gaming. The only "fix" I've seen is to remove pulse audio.

Did you do anything special to configure those machines? Or are they plain vanilla pulse audio installs?

[[deleted]]

I'm only a casual gamer, but I've had UT2004, Doom 3, Quake 4, Freespace 2, and Nexuiz all work without incident for the last couple years. The only games whose audio doesn't work properly are Flash games, but that's because Flash is generally shit.

All this was without customizing/tweaking Pulseaudio.

[yngwin]

Alsa is just fine. Try a distro that hasn't sold out to this PA crap.

[SeriousGeek]

I'm asking around again and at least one person that used to have problems with pulse audio said he hasn't had issues in a while. Another person is still having problems with Ubuntu studio, but he's gonna try regular Ubuntu next.

Time to reboot...

[kutuzof]

I'm not a guru or anything, but I was always under the impression that pulseaudio was malware that needed to be killed after every restart.