Re: Reduce CPU usage of PulseAudio on NetBSD

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Wed, 23 Dec 2015, Kamil Rytarowski wrote:
> The simplest way to reduce >90% CPU usage to <1% on a NetBSD host is the 
> following set of two commands (assuming running daemon):

I have another method.

mv /usr/pkg/bin/pulseaudio /usr/pkg/bin/disabled.turd.pulseaudio

(I don't pkg_delete it due to dependency BS that I wish wasn't there)

Pulse audio is un-friendly toward all unix-like platforms (including and 
especially Linux). I have had every problem in the book with Pulse audio 
on _Linux_. I haven't the disrespect to defile my NetBSD system with it 
(perish the thought!). I personally consider it hostile software and 
counterproductive to even engage with it. It's not limited to taking up 
90+ % of the CPU. It also:

* Has buffering issues which cause sound to stutter, jitter, and basically
  sound like crap. Today. Now. On at least two Linux systems I'm forced to
  use. One is Ubuntu and the other is Fedora and they are patched to the
  hilt. It often takes more CPU than the games I play under Linux do!

* Doesn't actually support some of the sampling rates it advertises to
  clients. Ie.. insufficient checking on it's operational parameters. Then
  it won't resample, or if it does, does so in non-realtime (ie.. poorly).

* Almost never works with the hardware mixer on the systems I use. Ie..
  changing volume either creates noise, doesn't work, or mutes the whole
  channel and makes it un-adjustable.

* Skips and jitters in bully-victim scenarios with other system daemons as
  they try to do (often very little) tasks on the system.

* Mis-identifies mixer controls (ie.. headphone port is wrong or missing,
  line out is mismatched etc..)

* Bugs out or overreacts to sound events like removing a headphone from
  the headphone jack.

* SIGSEGV then takes some client apps with it (Chrome, Skype, etc..).

* Often skips or jitters the audio while adjusting volume

* Breaks or jitters input streams when adjusting line-in or mic volume.

* Often has a freak out when one client plays at one rate then another
  client uses a faster rate. The first (slower) client then goes at the
  higher rate and you get Alvin and the Chipmunks.

* Tends to "ruin" other configurations. Ie.. it creates dependencies in
  Ubuntu that (especially recently) make it impossible to uninstall and
  replace with alternatives without custom compiling packages. For
  example, you can't get esound anymore since they force a replacement
  pulseaudio-esound compatibility crapware (that's shares all of
  Pulseaudio's issues plus adds a few of it's own). You'll have big
  problems just going back to ALSA or OSS. Especially with their version
  of mplayer (where they've married it to pulseaudio too closely).

* Pulseaudio is way too over-complicated. It's some dream of Lennarts while
  he was high at a rave or something. Maybe he fancies himself some kind
  of sound engineer. *YAWN* *SHRUG*. Here's me ... wholly unimpressed.
  Every single other solution in the same or similar space is MUCH better.
  I'm thinking Jack, Arts, Esound, etc.. They may not have all the silly
  features, but they WORK, generally. I've had pulseaudio on at least 7
  machines. It worked acceptably on ONE. Hand waving about "it's better
  now" was old 3 years ago. It's not better, just more bloated.

* I have (way) more complaints and buggy, anger inducing experiences with
  Pulseaudio, but I guess I'll end here. I consider it one of the biggest
  PoS parts of Linux overall. It's like the Kyoto Climate accords. It
  sucks the air out of the room and provides a very sub-par "solution"
  (that isn't) that occupies the space where something much better should
  be. I doubt anyone is still reading this, so I'll leave my further
  issues as an exercise for those who still choose to drink the
  Lennartix^H^H^H Uhh, I mean Linux kool-aid. I'm an enemy of Lennart's
  way of doing things and I'm not the least bit ashamed to say so
  (long and loud).

We ought to do everything we can to avoid having it taint NetBSD in any 
way. Remove it, deprecate it, and stub it out. Just because the Linux 
crowd thinks something is wonderful doesn't mean it is. The unwashed 
masses are usually dead wrong.

Thanks,
  Swift

> pacmd "unload-module module-oss"
> pacmd "load-module module-oss mmap=0 device=/dev/audio"
>
> In general there is an assumption of Linux-like feature to efficiently
> poll(2) mmap'ed region. This operation is very slow on NetBSD.
>
> This is a temporary walk-around, I will be looking for a permanent one.
>
> Credit: mlelstv and medfly from #netbsd @ FreeNode.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWeej7AAoJEEuzCOmwLnZsBegP/0MisTeZQ8Xmn67yI7ijvDAi
> EQKopIdmLpk3onKlU9xb8F5nXpTy9nzII2WnuDsAjlpPXauWx+AcdFMUZ/wlM/Fm
> JwVVYv3mIkqOnsdRCM/UExgreCL3xo9khVPsMeBYGjhkTb9etLGXuRiw5T5Hh9sN
> jV8+KWD/JuFYp1Ug0vYcX1VhJZK8uMQY6oFhh13JHDVUBjJ3UNVN+ZZMuh6YV4Is
> SAqnLp8DJ0/DDmNsZSo+1l1l3Euh4+wE0IDlPs/FmW/+A5Fz6W2ff3145pVtXiYV
> FQRAXTicE8OeupvT3UxWB+tzwJAyrY6gXaqYDMxouJ27v/RcCBAs5NWYnniCnam9
> B9Wj1he3LvUKQjYMD6WkG6AHvRU5i3yvYqSajZIcsvJOKSGl+FlhTVnELXDnz5yL
> zEKskH74LsStxDW+Q4u34Mh20lUrSzLsfy1byhIsL7ZdIbY8YbtcdzT+8yDdDw/e
> kSYVbAeFqfazaDgOYqe4leqQpJ888Of4saoct8T2z0/RZWBJ1oRqoj/Lroopj9Hp
> 36t5awogZwtVW4Vq5sVmYRbFa8BSgr2H/YVxZokLwgHpdgBzH4b7AODIGkjPDkW4
> 6jhAagFDq3DbkAqaT+H/QE4/MZm0wvEQDsKgANYW/PdNEW5V+QD7eaeEz0nH57hh
> Nh4Eeic/w0XUimCeQ02L
> =+2Mi
> -----END PGP SIGNATURE-----