PulseAudio 2.0 Runs On HURD, Has Jack Detection

[allquixotic]

Nonsense. GTK and Qt can coexist just fine, and installing GTK won't kill all your Qt applications.

PulseAudio is a new sound system which broke pretty much all software, and required the sound backend of pretty much everything to either be rewritten, or updated so Linux-native sound system emulation doesn't barf.

I'm willing to revisit PulseAudio if it one day does live up to the hype. So far, though, it offers nothing of value to me (ALSA has worked flawlessly for me for at least 8 years), and with its history, I'm willing to wait a couple of years. ESD and aRts have left scars.

Give me an example of the latest stable release of an application that will not "coexist" with PulseAudio?

Seriously, I can't think of an example and I've used hundreds of audio-playing apps.

OSS apps? Use osspd.

ALSA apps? Use the pulse plugin for libasound2. Installed by default and configured on all modern distros. Bugfixes galore have hit it in recent months/years, so if you aren't using the latest stable distro (and NOT Debian Stable, that doesn't count), either upgrade or stop whining.

OpenAL-soft apps? Solved problem; works well with native pulseaudio API as backend.

SDL apps? Solved problem; works well with native pulseaudio API as backend.

Proprietary apps? Flash, Skype, Savage 2, Heroes of Newerth, HIB games, VMware Workstation, Second Life all work out of the box... do I need to continue?

JACK apps? Start jackd and run PulseAudio on top of it, problem solved. AFAIK Ubuntu and Fedora are working on a way to get JACK to automatically start-up and run PA on top of it whenever something needs to use JACK. It'd certainly be nice to have it automatically just work, but hey, if you're using ALSA or OSSv4, you're used to inscrutable configuration files already.

And let's not forget that almost any software you can download from a distribution today is working with PA out of the box. People test this and file bugs when things aren't working. So the primary cases where PA doesn't work out of the box are going to be third party apps, and let's face it, third-party developers can do whatever the fuck they want, even if they explicitly desire to make their app as incompatible as possible with PulseAudio by statically linking to a compiled-in libasound2, initializing ALSA with snd_pcm_open("hw:0") and encrypt the string in the binary and use an executable packer so you can't easily binary hack it to open the default pulse device either.

This isn't a new problem. ANY platform that allows arbitrary third-party machine code to execute is going to have incompatibility problems. I can't tell you how many times I've run a Windows program and watch it BSOD my machine or wreak similar havoc. The hope is that most software that people will ever want can be provided by the distro, so that the benefit can be enjoyed, of making sure the distro integrates everything and ensures that it all works together. We're not 100% there yet, but PulseAudio is the last best hope for Linux audio. If you don't want Linux audio to graduate out of the 90s, you're welcome to run Debian Stable or RHEL5.

[pingufunkybeat]

Give me an example of the latest stable release of an application that will not "coexist" with PulseAudio?

Way to go completely off-topic and off-tangent.

PulseAudio DID break all those things. It took years to fix the fallout.

Therefore, it is nothing like GTK or Qt. Updating Qt NEVER breaks GTK apps, and it certainly doesn't require xterm to be rewritten and piped through an emulation layer.

[allquixotic]

Way to go completely off-topic and off-tangent.

How is it off-topic? Your main complaint in your reply was that Pulse didn't "coexist" with other audio APIs or other audio apps that don't natively access the PA API. And yet...

PulseAudio DID break all those things. It took years to fix the fallout. [emphasis mine]

Even you concede that it TOOK (PAST TENSE) years to fix it, which implies that, NOW, it is fixed. No shit, sherlock! So what if it took years IN THE PAST to fix it?! It's fixed now, so why are you still whining? Are you also going to complain that KMS broke UMS and it took years to get KMS+DRI2+G3D working reasonably well? Shit changes, and change is disruptive. Live with it or put on a tinfoil hat and live in a cave with a 1990s era hardware mixing soundcard running RHEL4.

Therefore, it is nothing like GTK or Qt. Updating Qt NEVER breaks GTK apps, and it certainly doesn't require xterm to be rewritten and piped through an emulation layer.

Actually, I have seen MANY instances where running a KDE desktop will cause GTK apps to render in a default theme that looks like Windows 95, which can be an example of breakage. The reverse sometimes happens too. And the only way to get everything to look the same is to install compatibility libraries, which don't always exist e.g. if you're running a 32-bit app on a 64-bit system. So there's plenty of breakage to be had there.

Anyway, your argument that PulseAudio required apps to be rewritten is moot, because it's in the past for all but a few apps. You're the one going off on a tangent -- this is a thread about PulseAudio 2.0 in May of 2012, and we are not talking about how PulseAudio used to suck because it used to cause a lot of growing pains for people way back in 2007. The reality of today is that PA does coexist rather nicely on the desktop for all but an extreme minority, and my point is further confirmed by the fact that you failed to name a single application falling into the category of not coexisting well with PulseAudio.

[LightBit]

Live with it or put on a tinfoil hat and live in a cave with a 1990s era hardware mixing soundcard running RHEL4..

What's wrong with hardware mixing?
But RHEL4 isn't from 1990s era.

[pingufunkybeat]

No my dear friend, the only issue is your statement that PulseAudio is something like GTK or Qt, which is plain silly and still wrong. It is nothing like GTK or Qt. PulseAudio plays along with other stuff only if you pipe everything through PulseAudio. It is a layer on top of ALSA and everything goes through it, emulated or not.

SDL is like Qt or GTK. You can use it for sound if you want to. You don't have to rewrite everything to use SDL.

My criticism of PulseAudio was and remains the fact that it doesn't actually do anything useful for me, and it still causes people problems, so I'll wait it out, like I'm waiting out to see how BTRFS plays out, or Wayland. For the time being, ALSA is just fine and dandy.

[e8hffff]

My criticism of PulseAudio was and remains the fact that it doesn't actually do anything useful for me, and it still causes people problems, so I'll wait it out, like I'm waiting out to see how BTRFS plays out, or Wayland. For the time being, ALSA is just fine and dandy.

PulseAudio has made my user experience much more pleasurable. I actually can rely on it with my applications to all sounding off as they should. The only problem I've had is Wine, but it's using ALSA and as someone said OpenAL.

What I would like is people like you to support front-line code like PulseAudio, and inspire others to develop more features like easier virtual channel mixing, else we will be stuck in the 90's. Example, it's a nightmare for me to record an application's sound without doing command-line tricks or it recording the whole main mixer. It's simply not good enough and a short-coming for Linux desktop.

Another blight, is sound devices not having symbolic names. Like who expects Linux to become mainstream when applications are asking a user to pick a sound device named something like 'pcmC0D0c' or 'hwC0D2'... It's a ridiculous situation and it's caused by those that wont shift up.

[Larian]

Give me an example of the latest stable release of an application that will not "coexist" with PulseAudio?

Proprietary apps? Flash, Skype, Savage 2, Heroes of Newerth, HIB games, VMware Workstation, Second Life all work out of the box... do I need to continue?

How about three? After a system update, audio was broken for me in Doom 3 and Quake 4. I have to specify OSS in the command line to get both games to launch with sound: "padsp <app>" doesn't work. Further, I almost always have to issue a "pulseaudio -k" command as a prerequisite when launching just about anything in WINE if I want smooth audio playback - otherwise sound is a garbled mess, and that's if it works at all. In fairness, this last problem cropped up only after I updated to Ubuntu 12.04.

If I recall correctly, back in my pre-pulse days running ALSA, none of this happened. With the "Latest & Greatest" Ubuntu/PulseAudio, I'm having to use workarounds for things I didn't have to do before.

In my view, and I'm being as sincere and respectful as I can possibly be, if you believe PA to be bulletproof, one-size-fits-all, and the Best Thing Ever, I would advise you to buy a horse with shorter legs. These behaviors I describe above are nothing less than broken. Just because I've been able to scrape workarounds off the Internet doesn't mean the problem is solved.

[e8hffff]

How about three? After a system update, audio was broken for me in Doom 3 and Quake 4. I have to specify OSS in the command line to get both games to launch with sound: "padsp <app>" doesn't work. Further, I almost always have to issue a "pulseaudio -k" command as a prerequisite when launching just about anything in WINE if I want smooth audio playback - otherwise sound is a garbled mess, and that's if it works at all. In fairness, this last problem cropped up only after I updated to Ubuntu 12.04.

If I recall correctly, back in my pre-pulse days running ALSA, none of this happened. With the "Latest & Greatest" Ubuntu/PulseAudio, I'm having to use workarounds for things I didn't have to do before...

You must admit Wine is heavily reliant on good latency, so if your hardware is a setback then running any API's closer to the kernel or hardware, is the better.

Personally I've noticed Wine improvements with sound only with recent releases, older versions were shocking. Maybe this is due to OpenAL.

[nightmarex]

Say what?

PulseAudio is the best thing happened to Linux regarding sound.

What would you rather have, everyone using ALSA or OSS and only having one sound application able to run at once?

I use ALSA I can use many app's at the same time accessing sound; mplayer, vlc,audacity all at once no problem (of course multiple things going on sounds like shit anyway) . There is a problem with accessing read/write from different HW sources maybe that's what you meant?

[GreatEmerald]

Oh yea, speaking of which, PulseAudio is also quite nice for more advanced recordings. For instance, with ALSA, you can set it to record the sound and the microphone off your sound card, but they will be combined into one without any way of splitting them. With PA, you have the ability to record the input and the monitor separately, allowing you to post-process the audio tracks (in my case, remove noise and equalise the microphone input).

Mind you, I still prefer recording the microphone off my integrated sound chip than my dedicated sound card, as the latter doesn't have any volume boost support, which is due to pretty lousy drivers for the X-Fi emu20k1 chip (which are hardly better on Windows, even...).

About PA device names, they're pretty unreadable, but they're like GUIDs. You can be sure you're recording the right thing at all times, and it won't change to something else when changing card priority or the number of installed cards. You can also make an alias, as far as I know.