[SOLVED] Doc for building extra/pure-alsa-system

elcore · 12-19-2020, 07:31 AM

Not going to host a pulse library for decoration purpose, removed it before pure-alsa was official and will remove it again.
Just waiting for feature freeze rc1 or rc2 if there will be any, if not well that's cool too.

HalseyTaylor · 12-19-2020, 10:48 AM

A debate, or mini flame war, on pulse/no-pulse serves no purpose. There are just some of us who would like to continue using pure-alsa-system and it's understandable that the slack maintainers have better things to do than support one.

Unfortunately, the mirror I use no longer has the extra/pure-alsa-system source tree so the slackbuild scripts are absent.

Alien Bob · 12-19-2020, 10:56 AM

Quote:

Originally Posted by HalseyTaylor

A debate, or mini flame war, on pulse/no-pulse serves no purpose. There are just some of us who would like to continue using pure-alsa-system and it's understandable that the slack maintainers have better things to do than support one.

Unfortunately, the mirror I use no longer has the extra/pure-alsa-system source tree so the slackbuild scripts are absent.

There is no separate source tree, the normal package sources are used for both ALSA and Pulseaudio builds.
Read https://slackware.nl/slackware/slack...stem.buildlist which contains everything you need to know. The make_world.sh" script is located in the main ./source directory.

the3dfxdude · 12-19-2020, 02:12 PM

Quote:

Originally Posted by Didier Spaier

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 its pure-ALSA a time that he could have used instead for something more useful for many people. Days have only 24h00.

Besides the ad hominin argument of "not eager to learn", I mean there must be so few people out there using alternative sound management? Right? I guess AlienBob must be wasting his time forking Slackware to make DAW that works with JACK then? So few people that Pat has been able to offer an option anyway? Pulseaudio works sooooo perfectly...

I mean despite what Pat chooses, the fact still remains. People are not using Pulseaudio, and we are still present in the Slackware user base. The configuration of a Pulseaudio dumb-pipe to ALSA isn't exactly true. Pulseaudio when activated by an application still screws with your settings. A pure ALSA system has its benefit of not triggering any pulseaudio code, and all packaged applications in slackware will work with ALSA directly fine.

I don't know that the trend of splitting distros on the lines of sound management will continue before Linux geeks and devs get their act together and make something that just works. But despite what is happening I have no problem with people using OSS, ALSA, Pulseaudio, JACK. But the fact of the matter is ALSA is still here in the kernel, and a distro that provides ALSA as the fully functional sound system base (one where anyone can add any sound management system OPTIONALLY) might be prudent since Pulseaudio may be going away actually, and almost nothing exclusively requires it. Let's hope PipeWire doesn't repeat some mistakes.

Didier Spaier · 12-19-2020, 03:22 PM

Quote:

Originally Posted by the3dfxdude

Pulseaudio when activated by an application still screws with your settings.

Wrong. In Slint we ship Pulseaudio with these lines in /etc/pulse/defaut.pa:

Code:

### In Slint, we want to share audio resources between speech apps that
### rely on alsa and other apps that rely on pulseaudio.  
load-module module-alsa-sink device=dmix
load-module module-alsa-source device=dsnoop

so the settings you make with alsamixer or amixer are not modified by PulseAudio in any way, as it just sends the streams to dmix. Incidentally we do not start pulseaudio with a session, but indeed only when an application requests it. Of course we don't do the reverse redirection either, so (and as Patrick does in the pure-alsa settings) we don't include these lines in asound.conf:

Code:

pcm.default pulse
ctl.default pulse

As far as I know that's all it takes to make ALSA and PulseAudio coexist peacefully.

Also, if an application wants PulseAudio and you really prefer to use ALSA, oftentimes you can just run it through apulse instead of rebuilding it.

HalseyTaylor · 12-20-2020, 07:55 AM

Ah, very odd... can see source/pure-alsa-system today... and there's pure-alsa-system.buildlist!

Perfect! Solved.