I think it ultimately comes down to the fact that I'm solely online for my degree. There just isn't any software that can lock down Linux to the degree the accreditation agencies likely need to not require proctored tests. I imagine if I was actually attending classes, there would be no limitations with running Linux. Most classes that require Word documents to be uploaded will also take pdf files, so you don't have to worry about LO document formatting not being correct when opened in Word.

UPDATE (reversal) - Well that little foray not only didn't last a year or three, it barely lasted a month. I still prefer ALSA but for essentially the same reasons Patrick had to finally cave, so have I. I re-enabled pulseaudio today simply because although apulse did help, there is just too much already that's a pita w/o actually running pulseaudio. I'd like to again thank everyone who responded since I learned something from almost everyone. Good Fortune to all.

1 members found this post helpful.

Did you keep to your plan and did not try to uninstall pulseaudio the whole time? Just reference back to my comment in thread post #44. I've been running good on all of my machines this way for over a year. If you had a 14.1 setup you liked, it should still work fine if you make sure you have no pulseaudio. And I haven't found a need for apulse. I was skeptical of a good coexist setup with the requirements you had set.

At one time I wanted to do a true co-exist, where whether automatically or by "the flip of a toggle script" I could switch up. That level of complexity doesn't seem worth any benefit once i got into exactly how such a thing might be done. I didn't completely remove pulseaudio, though, I just disabled spawning, disabled the asound.conf replacement and enable ~/.asoundrc. I experienced some oddities where I would discover pulseaudio running and not know how it even got started but I suspect Firefox may have dome that. That seemed to stop after I installed apulse and I used apulse as a specific launch argument to try to help tame Steam which had grown useless in 64bit 14.2 multilib.

ALSA did of course work as expected with the exception of Steam which can be a royal pita to troubleshoot because some games can't be run from command line (guess at errors anyone?), others are buried under layers of shell scripts, and to make matters worse, Steam auto updates which can no longer be turned off, which apparently is infamous for breaking things. I made a separate thread here about Steam and multilib but multilib wasn't the issue, mostly it was pulseaudio. Games that used to run and work properly suddenly didn't. 32bit games ran but sound went crazy as in up in pitch a couple of octaves with no changes done by me after 2 weeks of running correctly. The sole 64bit game I have, ran 3 or 4 times and then suddenly wouldn't even launch. Re-enabling pulseaudio solved all that, thanks to a few things I learned from responders in this thread, and the only loss is I need to see if I can live with the limitations on pulseaudio compliant Jack and hope it will only grow in time to solve those limitations. In a pinch I can always just boot 14.0 32bit which has a perfectly fine ALSA system and working DAW.

Actually that is very interesting, and strange. Last month I installed a full 64-bit multilib setup and steam on one of my systems for the first time. Of course, without pulseaudio. There are no problems like that here. No sound problems at all. On the other hand, going back in time to when I tried to run pulseaudio "disabled", even normal applications would do strange things as you say, until I "enabled" pulseaudio. I did not like the pulseaudio device management when enabled either, so it got pulled out of the system completely.

Anyway I don't think there actually is a strong dependency on pulseaudio in steam. I think the problem you are seeing is more inside pulseaudio itself.

1 members found this post helpful.

I agree. I imagine if i opted out of installing Bluetooth support and Pulse at installation, or possibly just removed all traces of it after install, it might work fine, especially with apulse as a safety net. Since I now have a test partition all setup I will try this soon. I certainly wish Steam would make it easier/possible to research and troubleshoot executables as not only would I like to see the choke point for such recent items as Deus Ex but I am particularly curious as to why my trusty old HL2 began to play sounds extremely "boosted" in pitch LOL. It was entertaining for a minute to hear Alyx and company sound like chipmonks, but ultimately puzzling and annoying.

We do have to contend with dependencies created by agenda rather than actual usage, though. I recall when MS first took over Skype and enforced a version update that broke with ALSA, simply renaming the old version to the new version (no alteration of libraries) allowed the old version to work perfectly. So such shenanigans can muddy the water as to what really fails or succeeds.

1 members found this post helpful.

I've wrestled with pulseaudio for a while. To me it seems it has become a requirement for more and more software, so sadly taking an ALSA only route reduces the software I can run (mainly voip and some games). On the other hand, I just can't live with the "dumbed down" audio that pulseaudio provides. The biggest annoyance for me was not being able to switch from front speakers to headphones with pulse (it mutes all output once you mute the front speakers, and yes I tried all the "disable auto-mute" and other tricks). So after much testing, I came up with a viable solution for me.

To get ALSA mixer control back of my soundcards and stop pulseaudio messing with them:
I masked out the module-udev-detect section in default.pa, and added in specific alsa loading for my cards instead, like:

load-module module-alsa-sink device=hw:<name from aplay -l> rate=44100 sink_name=<a_sink_name>
update-sink-proplist <a_sink_name> device.description=<The label you get in PAmixer>
load-module module-alsa-source device=hw:<name from arecord -l> source_name=<a_source_name>
update-source-proplist <a_source_name> device.description=<The label you get in PAmixer>

Above is for one card, repeat for other cards...

Then I also masked out bits I didn't need (like module-role-cork, intended-roles).

My .asoundrc still points everything at pulseaudio, so I still suffer from unpredictable latencies, but at least I can use qasmixer now to fully control my soundcards, and I only need to touch pulseaudio's controls to shift which card a stream is using. The only other feature I've lost is the ability to hot plug external soundcards and have them auto detected by pulse, but that doesn't bother me. They still show up as ALSA devices, and pulseaudio leaves them alone.

I did try the Jack route, but I never got it to work glitch free, possibly because I was using Jack2, I don't know. But I gave up on it.

Also worth noting! You still see "resample-method = src-sinc-best-quality" suggested as a setting in daemon.conf in a lot of places (including freedesktop documentation!). That doesn't exist in Pulseaudio any more. "resample-method = speex-float-10" is now the best available resampler.

1 members found this post helpful.