It makes sense for slackware maintainers to abandon extra/pure-alsa-system. It looks like there's enough other stuff to worry about.

However....

It would be nice to get a faq or some other instructions on how we can do our own source builds and make pure-alsa-system installs without pulse.

Slackware has always done a great job of supporting the freedom to do the install you want. Publishing guidance on a roll-yer-own pure-alsa-system is very much in keeping with that.

A debate on pulse/no-pulse serves no purpose. There are just some of us who would like to continue using pure-alsa-system.

The packages in concern are here:
https://mirrors.slackware.com/slackw...e-alsa-system/

Have a look at there respective source directories, as they can be built with our without pulseaudio.

Check the SlackBuilds to see if a configuration option differ for pulde alsa.

I is also possible that pulse be picked as a dependency if installed when building.

Good luck

If people are asking for how to use ALSA directly without any pulseaudio installed, wouldn't it save so much time just to provide the packages in the first place? Wouldn't it be even better if Pat just kept providing the packages? You asking for a doc is evidence that people still want this.

It would save time for a few people wanting to keep something just because they are used to it (I refrained to write: and are not eager to learn how to configure another tool to behave like what they are used to), but would make Patrick spend on pure-ALSA a time that he could have used instead for something more useful for many people. Days have only 24h00.

4 members found this post helpful.

I setup Pulse so I can switch between it and ALSA. People could take those scripts but this one would be a challenge for people with slower computers to build.

Come on, people!

This PulseAudio hatin' should stop!

For the Santa Claus sake, wake up and look around you! In the near future the PulseAudio will become obsolete already!

There are already talks about replacing PulseAudio with its successor, PipeWire! Which BTW would NOT be optional just like LinuxPAM and Kerberos cannot be optionals.

And Fedora 34 will be released at the begin of the '21 with PipeWire as default audio-server. Guess what will happens next?

And why we should positively discriminate those few who wants pure ALSA, with no real reason?

IF the pure-ALSA is kept, I propose to be added yet another alternate trees for OSS and SNDIO.

Yes, man! Let's go BSD all the way!

There are also people who thinks that ALSA is also "an unnecessary layer of complexity"

1 members found this post helpful.

As I said somewhere there, I still believe that an alternate kernel, tracking the latest one on kernel.org would be thousand times more useful and used by much many people than that pure-ALSA.

I would be very glad if Mr. Volkerding will stop wasting his precious and limited work time to satisfy some rebels without a cause. IF we ask one PulseAudio hatter, he has no idea why he hate PA, after all...

1 members found this post helpful.

There is no such thing like an absolute freedom, because an operating system should make some sensible design choices.

A good example was the LinuxPAM and Kerberos. Which was hugely more useful than this pure-ALSA system for the people trying to use Slackware into business or (small) offices. However, was not so simple to be post-added by users to Slackware.

Hence, I believe that you should accept that the PulseAudio is as a design choice of Slackware and to trust our BDFL that the PulseAudio is good for you...

Even as a (dumb) proxy for some PulseAudio-only software.

1 members found this post helpful.

That would be nice but I fail at
When following instructions I end with no sound at all...

First of all, WHY the heck you use that "quote" command, and NOT the "code" command instead? Did you see how meaningless looks your post when it is quoted?

Look here how it would have been shown IF you used "code" instead of the smart-ass "quote"

Feel free then to open a thread about configuring PulseAudio as proxy to ALSA in Slackware, if the Arch Linux instructions does not work for you. There are people who managed to do that in Slackware. For example: Mr. Hameleers, GAZL, enorbet - just to enumerate few.

I for one I do not care about PulseAudio vs. ALSA, being rather busy to play with PipeWire.

However, I believe that the end-user configuring PulseAudio as being just a proxy to ALSA is the proper way for those who want to use ALSA mainly. And this does not requires an alternate packages tree.

1 members found this post helpful.

Yes, I have Pulseaudio mitigated but I will possibly jump for joy when Pipewire or something like it relegates pulseaudio to a bad memory.

2 members found this post helpful.

Probably because the quick reply doesn't have it and that, quoting a sentence rather than copying some code, it sounded apropriate.
Anyway, got your point and agree, even if it sounded a bit harsh.

Could be considered off-topic but felt like having some advice on that might be a good alternative for the aimed goal of the topic.

Hear hear!
Count me among those. ALSA has never been as good as OSS.

1 members found this post helpful.

FWIW, I was never particularly fond of ALSA if it meant having to edit a text configuration file simply because I wanted to use HDMI audio instead of Line Out, or vice versa. At least for me, PulseAudio just works.

If Pipewire is as easy to setup and use, fine, by all means replace PA.

1 members found this post helpful.

No. It still has the same issue that it had on day one: that it's a per-user daemon architecture on a multi-user system. Now, if you're using linux as a single user system that won't bother you and in your blinkered world-view pulseaudio is fine¹, but some folks run multi-user workflows and pulseaudio just does not fit.

My personal view is that Pat shouldn't need to provide the pure-alsa packages: not because I think pulseaudio is fine, but because I know it is easily bypassed through configuration alone.

---
¹ well, "fine" except for the added latency that bothers some folk, and its tendency for CPU starvation because linux is not a real-time OS.