PulseAudio Adds Memfd Transport Support

[Ericg]

... and never played games.

Playing a game through Wine right now, with Pulse active. No obvious problems to report. Hell, thats even an extra abstraction layer ontop.

[oleid]

... and never played games.

Some old self versions used to make problems with pulse. But that's long past...

[patrakov]

Now on topic.

I believe that one thing is unfixably wrong with PulseAudio in relation to secure application containers. Namely, it performs work (eats CPU) on behalf of clients (other processes). The problem is that a client can, even from a secure container, overload PulseAudio (up to the point of it exhausting its real-time budget and being killed by the kernel with SIGKILL, thus denying service to other clients) by sending a ton of streams which need CPU-heavy resampling, or by repeatedly saying "forget what I have just sent, here is the new version".

Dmix didn't have this "assigned work" problem at all, each process did its resampling and mixing by itself, with the CPU time eaten only by it and accounted only to it. But dmix means shared read-write access to the mixing buffer and the sound card buffer (which is unacceptable for secure containers), as well as inability to move streams to a different sound card on the fly, or mix to a "strange" device (such as a BlueTooth headset or a software DTS encoder) which is not a shared memory buffer with PCM samples that the hardware reads from. So not a solution either.

[SpyroRyder]

So I've actually also experienced that crackling problem on Pulse. It was caused by Firefox and usually went away if I restarted Pulse. I had it for about 3 months and then it never came back. However, that was the first problem I have had with pulse since early 2009. I've never had any issues with games, never with audio programs such as audacity or that skype call recorder, and never with any video players. The design could be better (flat volume isn't needed on desktop machines) but like someone above said what we really need is a total redesign of the audio subsystem. It sucks worse than the graphics subsystem ever has

[mjog]

Playing a game through Wine right now, with Pulse active. No obvious problems to report. Hell, thats even an extra abstraction layer ontop.

Yeah, I used to do just this all the time. Happily there's only one game left that I'm interested in that hasn't been ported to Linux - those that have all work natively using PA no problem at all.

[nanonyme]

I use Linux since 2007 and can't understand why people hate pulse audio so much.. It simply works, and I never have to think about it until a see people complaining on phoronix..

Because back in 2007 many desktop users still had sound cards moved from machine to machine originating from 90's where hardware mixing was a normal thing to have. PA ideology that software mixing is the only thing that exists makes a lot of sense these days. Per-user volume control is something people didn't feel they needed, it had to be sold and people needed to get accustomed to it. Now it's a normal thing to have. Windows users have equivalent of PA in both regards

[bkor]

Adding that PulseAudio just works for many years. No crackling noises, usually around 0% CPU (Pentium N3700.. it is not fast), very good quality sound. For people experiencing issues, maybe look into old configuration bits you still have?

[mlau]

Sounds more like you have an issue with ALSA rather than PulseAudio.

ALSA alone doesn't do that pop noise when it restores volume, only the PA daemon when it starts.

[mdias]

Am I the only one who believes in the KISS principle? The smaller a program the easier it is to fix bugs, that should be obvious.
How long did it take to make PulseAudio usable I wonder, and will it stay that way?

You must not forget that we're talking about an audio server here. Keeping it simple isn't really that easy. The program must:
- manage multi-channel cards
- inputs and outputs
- multiple cards
- multiple sampling frequencies and resampling
- all of these playing at the same time without issues
- hot plugging of soundcards (think USB headsets that have their own audio processing)
- bluetooth audio devices support
- be precise about timing/latency
- deal with a backend (ALSA) whose quality vary with hardware (some emit proper interrupts when buffers need filling, others don't work properly that way and need polling strategies, etc..)

Splitting such an integrated system into single-responsability programs also doesn't look like a very good idea. Implementing a system to allow such low-level communication between these programs would be a mess, not to mention the overhead...

Truth is, PA (assuming same version) is the same everywhere while ALSA is not (each driver may behave differently); so if most people don't have any issues with PA and a few do, there's a high probability the problem is an ALSA driver (or poorly configured PA).

[edit] I'm obviously refering to the kernel part of ALSA.

[hrkristian]

Without fail, every single Pulseaudio related thread there's at least one person going on a rampage against it.

I've had PA using 10% CPU time for no good reason, I've had the crackling sound, I've had other weirdness. That was way back when using Ubuntu, 8.04 and 10.04 period I think it was.

The only issue I've had with PA since moving to Arch around the time of Ubuntu 10.10 is when running audio through the equaliser (qpaeq), it can only handle one audio input at a time or I'll get skips in the sound output, but that's to do with qpaeq, not PA.

Honestly, couldn't help laughing at the "Pulseaudio is absolute trash! I mean it works now on Arch but I got burned once, so never again!", that is some fantastic irony right there. Grow up god damnit.