The latest ended up being done in two steps because the changes to Pulse config to comment out choosing ALSA as sink, did not get saved the first time.

1. The pulse daemons are gone, all of them, since when pipewire-enable got executed.
The change to xdg must have stopped them.
Removing the ALSA-as-sink had not got saved, so it was not done yet.

2. Second day, commented out that ALSA-as-sink line in default.pa.

3. The pulse daemon that crashed timidity at BOOT is still there the last two days. This is the original problem in the original post.
It is still intermittent, and timidity may work on some days, but the problem will be back the next day.
The error message states, that it is spawning a Pulse daemon. and it cannot connect to ALSA.

I thought that sometimes it stated that it cannot find the user directory, but that message is not there today, nor in the original posting.
It does not spawn 4 Pulse daemons, and never did.


Note: I do not doubt that the ALSA-as-sink may have spawned 4 Pulse daemons on your system, but there must be something different.
Maybe it is because you do not have Pipewire enabled ?

A. It is a mystery HOW that timidity starting up is triggering a Pulse daemon to start in the first place.
B. How is it a Pulse daemon, and not a Pipewire daemon that starts.
C. It is NOT a Pulse system daemon, it behaves like a client daemon in that it looks for the user directory.
D. The /etc/rc.d/rc.pulseaudio file is NOT EXECUTABLE.
E. Got any good ideas how to modify anything to give better information on this.

Taking out the timidity start code is NOT an option, as that does not provide any information on why this is happening with THIS Pulse setup.
It did not happen with the Linux 4.4 Pulse setup, but that has been setup as ALSA, Pulse disabled, for years.

X1. I doubt that asound.conf can be changed during boot, because I have not figured out any way to get ALSA to re-read that config file.
So changing asound.conf around timidity startup will not work, and will be very confusing.

X2. It appears that xdg is NOT working to stop Pulseaudio at boot time. This BOOT time Pulse daemon is trying to start.

X3. Corrupting the pulse config to stop the Pulse daemon will not work. Having the BOOT time pulse daemon crash does not help keep timidity running.

X4. Taking out the ALSA redirect to Pulse is an interesting option.

For the purposes of this sound setup tool, it is an admission that the ALSA redirect to Pulse is a failure. It will not work for any audio connect that does not happen after X-windows starts.
I would have to document that in the tool.

That sound setup selection would have to rely upon ALSA automatically using DMIX, and would not work on hardware where that does not happen automatically.
It is the ALSA documentation that is vague on this point, I cannot guarantee results therefore cannot trust it entirely in writing this tool.
The PULSE selection would either have to be "NO TIMIDITY" or would NOT be "Redirect ALSA through Pulse".

X5. And it comes back to the same question again. HOW is ALSA starting a PULSE daemon?
None of the X-windows support for auto-spawning a Pulse daemon is active at that time. It cannot be xdg that is spawning this BOOT time Pulse daemon. Is something being left from the last time that X-windows was running Pulse (from before Pipewire got installed) ?

Pulseaudio is spawned by the 'pulse' plugin from the alsa-plugins package. When your default output is defined as 'pulse' in asound.rc, you will send audio to pulseaudio, and spawn a pulseaudio daemon if one is not already running. There's a bit of documentation installed at /usr/doc/alsa-plugins-1.2.5/README-pulse, or you can find it online: https://fossies.org/linux/alsa-plugins/doc/README-pulse

If you are using the pulse plugin as the default device, then the chain of events should go:
Now if you break that chain by making pulseaudio unspawnable with "autospawn=no" in /etc/pulse/client.conf, then you will get errors reported at the asound.rc step.

You say you ran enable-pipewire, which would have made pulseaudio unspawnable.

The thing about pipewire, at least in slackware-15.0's version of it: it doesn't have autospawning/despawning ability. It is a dumb set of daemons that requires external daemon management tools, which are provided by the 'daemon' package in slackware. The means of starting pipewire on slackware 15.0 are through xdg autostart scripts, which will only be triggered on startup of an xdg compliant desktop environment like xfce or plasma. At boot time they will not be started, i.e. if you boot to runlevel 3 then pipewire will not be running, nor will it get autospawned by anything. I'm not sure if this is any different in -current these days, but its limited to graphical desktop use in slackware-15.0's default setup.

If you are running some kind of script out of rc.local to play a sound at boot then you'd be best off with either of the following:

1. Sticking with pulseaudio by running the 'disable-pipewire' script, with that module-alsa-sink problem cleared up, autospawning should work once re-enabled. Unlike pipewire, pulseaudio is able to autospawn when something plays audio from a boot script.

2. Not using the pulse plugin in asound.rc so timidity sends audio to alsa directly, then setting up pulseaudio as a simple pipe to alsa so that you can still use graphical desktop and browser audio.

If you need sound to play at boot time, pipewire will probably not work (at least from my experience with it).

1 members found this post helpful.

That reference for desktop entry 'hidden' usage is kind of trash. I was looking at the xdg autostart specification today and noticed they provided much better info. I'll quote the useful bits below:
The enable/disable pipewire bits are just doing that system wide instead.

Pulseaudio has security issues and it needs to go.

Thank you for the information.
As I said, this was to give PULSE the best setup that I could.
I would not be recompiling ALSA or timidity because I have other audio choices that do not need that.

I will incorporate this setup into my tool as the PULSE selection.
Personally, I will be moving on to the DMIX option, as I expect that will solve the most problems.
I may even find some solution to this problem.
I will start a new thread for problems with DMIX.

This PULSE setup does not tolerate timidity startup, as the original problem of this thread still remains.
I will leave this open in case someone with personal experience has something to relate regarding getting PulseAudio to tolerate timidity.
I do not want to try to make any more audio programs PulseAudio dependent, so will not be going with altering timidity.