"PulseAudio Is Still Awesome"

[duby229]

On Debian Sid ( I won't switch to Fedora any time soon 10q ) it's the default yet I can't have sound in more than one app at once, believe me a tried to follow all the guides, to no avail.
Also none of the pavucontrol / manager apps actually registered any sound or app being used, no mpd, no Opera ( flash / html5 ), no mplayer, no sdl2 game, nothing.

This may sound like a conspiracy theory, but that sounds like somebody built the package without a whole bunch of configure flags.

[andre30correia]

i don't have any problem with pulseaudio since 2011

[grege]

This may sound like a conspiracy theory, but that sounds like somebody built the package without a whole bunch of configure flags.

Except my Sid works flawlessly. People make wild statements about their own setup without mentioning the details.

[computerquip]

Have you seen these?
http://www.phoronix.com/scan.php?pag...tem&px=MTE1MDc

http://klang.eudyptula.org/

This seems to be the goal of Klang, but no real news to be heard of so far.

He quit due to an overwhelming negative response from Linux developers. It's hard to tell if he was capable of such a task but some of the responses he got were some serious hatred. Some of the early comments were removed but have a taste: http://www.reddit.com/r/linux/commen...ext_generation

EDIT: Oh and he got a massive trolling on Phoronix forums and some other forums as well.

[geearf]

I am not sure about people saying PA works great for most users..
I still have issues when running wine, to make it work okayish I have to hack some settings, but then the rest of my computer doesn't behave as well anymore... It's fairly annoying.

I used to wait for the new passthrough sink (that would allow passthrough streams to take precedence and pause everything else), but I don't know if it ever got in... I just switched to PCM outputting instead and that works so...
I'm not bashing PA here, I've been using it for years, but it's not good enough from where I stand.

[Rallos Zek]

With PulseAudio the sound system in Linux is good enough for end-users and most professionals. It is actually simple, coherent and flexible.

For sure ALSA is shit, but if a new sound API was to be included in the kernel, PulseAudio should definitely stay there in userspace and use the new API simply because it's the most advanced and complete Free sound server available. The only value provided by ALSA is the (poor) kernel hardware abstraction layer but PA does everything else and does it right.

I've found PulseAudio to be an excellent piece of software at all levels. It works much better than every other Linux audio library for almost every possible usecase. As a developer I also enjoyed the excellent sound API they provide. For instance with a single line I could enable audio cancelling and let PA determine if, with the current setup, audio cancelling is necessary, and potentially enable it live (while my app is playing) if the user plugs something etc. No lower-level system have access to the necessary information to do this : it should really be done in userspace unless the whole desktop is put in the kernel. Note that OS X and Windows now also include similar sound servers.

LOL If ALSA is shit then Pulse Audio is shit, iss and bile all rolled in to one.

Alsa is a POS. Always has been. It's just the entire Sound ecoystem for Linux has been a POS hodge podge and people don't like a PulseAudio for fixing and simplifying it across desktop environments inside Linux. I haven't touched PulseAudio configs for nearly 18 months. It just works.

Every time I try a Linux distro and have sound problems nine times out of ten its pulse audio and removing it makes my problems magically disappear. Pulse is pure shit, makes me miss the days of ESD and aRts.

[TeamBlackFox]

Every piece of hardware you have on your PC can only be controlled by one driver. This is for obvious reasons.

When I say blocking I/O, I mean there's no provision for multiple inputs to be handled to ALSA, it has a tendency to listen to one process at a time, which leads to very unpredictable behavior.

Yep. That's because that's where software dsp (including mixing) belongs. It serves 90%+ of the users' needs. If you have the need for low latency, go with Jack. ALSA may have flaws, yes, but I don't think exclusively locking your sound card is one of them.

Where I am now, BSD and Commercial UNIX-land, multiple sound systems is neither acceptable nor the norm. You don't simply tell someone that when as it turns our, JACK and PA don't have anywhere near the same API, so that forces a user to find a new program if the one they want to use relies on PulseAudio. So no, try again.

What Linux needs is to poop on users that:
- support hardware vendors that don't supply documentation
- can only argue on forums instead of actually opening bug reports and help debug problems
- only see their own special needs as needed to be flawless

Well good thing I'm not a GNU/Linux user anymore. I'm a BSD user, developer and supporter now. I also use commercial UNIX for hobbyist and work related stuff.

I do believe people complain because they do have problems, but less complaining and more bug reporting would help everyone. Linux gives you tons for free, filling bug reports is the least you can do.

Filing bug reports on Linux is a harrowing experience due to the inability, seemingly, of the developers to replicate a setup, or realizing that a power user with a lot of modifications or changes is sure to encounter bugs, and that such bugs should not be simply ignored because they're rare. I was told to fuck off, figuratively, in past reports. One of the reasons that drove me away as a user and developer.

This. I'm afraid any other attempt at adding another layer, or re-implementing one, will only make things worse. A Wayland-ish approach would be nice. Just cut right through the years of accumulated cruft, cast it aside and get right to the modern and functional. And existing software that can't adapt to it, is thusly not being maintained properly, and therefor can't be that important anyway (if it were, someone would step up).

Until then, would also wish ALSA/jack (or whatever is to blame) would stop spamming stderr whenever I run my programs, grrr...

I do this on BSD, especially FreeBSD, now. I'm a port maintainer, and eventually will work my way into the userland and kernel after my study of it is completed to a point I can contribute meaningful code. I feel the barrier to entry is somewhat higher on the BSDs, but this also keeps the morons like Kay and Poettering out, who I bet IRL couldn't engineer themselves out of a paper bag. One of my professors from my BS CIS program who teaches a class on System/390 Assembler among others told me that in the 25 years of reading shitty C, systemd and PulseAudio are in the top 20, along with GCC, Open64, screen, GStreamer, parts of XFree86, and Hurd. Then again, we're both heavy critics of some free software projects.

If I were to design a sound stack, it would consist of a kernel-space device driver which could communicate with a master set of userspace processes through STREAMS, it would have a centralised error log, autodetect device configuration with a set of sysctls to control it, and would be designed from the start to be multithreaded and capable of handling multiple sound inputs and mixing them through an optional curses based, realtime mixer module. STREAMS, in my opinion, is the only way to design this to where it doesn't suck, and uses a well-established, zero copy protocol for IPC.

[matt_g]

Anyone talking about OSS4 or doing sound mixing in kernel space (including the BSD guy above me) is either a) ignorant or b) a troll I assume both. It's clearly spelled out in a link in the very article for this thread why it's not done. http://0pointer.de/blog/projects/jeffrey-stedfast.html

Jeffrey thinks that audio mixing is nothing for userspace. Which is basically what OSS4 tries to do: mixing in kernel space. However, the future of PCM audio is floating points. Mixing them in kernel space is problematic because (at least on Linux) FP in kernel space is a no-no. Also, the kernel people made clear more than once that maths/decoding/encoding like this should happen in userspace. Quite honestly, doing the mixing in kernel space is probably one of the primary reasons why I think that OSS4 is a bad idea. The fancier your mixing gets (i.e. including resampling, upmixing, downmixing, DRC, ...) the more difficulties you will have to move such a complex, time-intensive code into the kernel.

I.e. Advanced mixing requires floating point ops - Linux kernel guys will not allow FP ops in kernel forget about it mixing in Linux has to be userspace code end of story. I'm happy BSD lets you use floating points ops in your kernel its not applicable to linux.

PA and Jack also have different use cases:

JACK has been designed for a very different purpose. It is optimized for low latency inter-application communication. It requires floating point samples, it knows nothing about channel mappings, it depends on every client to behave correctly. And so on, and so on. It is a sound server for audio production. For desktop applications it is however not well suited. For a desktop saving power is very important, one application misbehaving shouldn't have an effect on other application's playback; converting from/to FP all the time is not going to help battery life either. Please understand that for the purpose of pro audio you can make completely different compromises than you can do on the desktop. For example, while having 'glitch-free' is great for embedded and desktop use, it makes no sense at all for pro audio, and would only have a drawback on performance. So, please stop bringing up JACK again and again. It's just not the right tool for desktop audio, and this opinion is shared by the JACK developers themselves.

My take away from this is PA is a good system for general purpose audio "desktop" use and if you need to start caring about latency then JACK is what you want to work with. For my generic desktop use Pulse Audio has served me well if your having problems with

[89c51]

"Most people doing audio are on Macs?" Not necessarity! I got my start on audio reporting and never had nor wanted a Mac. I always considered Macs to be hard to use clunkers, sometimes with no mic jacks, always with an unfamiliar interface. I had been used to first old versions of Windows on public computers, then to Linux machines with GNOME 2, in both cases using Audacity to edit sound. It was the natural free and open source replacement for Cooledit, with no paid version needed to output to mp3. Outputting from Cooledit to .wav back in 2004 made files too big for websites, outputting to .ogg made files nobody would open from a default Windows machine because their players didn't handle it by default. That was on a Pentium laptop with a 2GB HDD and Windows 95 on it. It was replaced by a far superior Athon 500MHZ/10GB HDD machines with what was probably Debian Woody on it later that year. Sure as hell XMMS was more reliable than Winamp for playback when running as an unattended sound server!

Never claimed that you cant do it on linux. Its the convenience and the ease of use of Plug and play in macs whether it is a headset or the latest coolest console. On linux you have to use JACK for low latency. Its the wrong way. We need one thing.

[Chewi]

LOL If ALSA is shit then Pulse Audio is shit, iss and bile all rolled in to one.

You don't have to use PulseAudio on top of ALSA, use OSS as a backend if you're mad enough.

Haters are gonna hate and I've posted about this before so I'll spare you the details but I'll just stick a +1 for PA here to offset the negativity.