Puppy Linux Discussion Forum

Borrowed from BookwormPup64 (thanks @dimkr and @radky ), setup with pipewire and wireplumber (pulseaudio not needed to have installed), just for testing.
Not really sure what's the idea exactly behind this setup, pipewire and wireplumber are running as spot, probably it's for to make sure that applications running as root and as spot work ok with sound.
My gut feeling says that I like it

20pipewire.sfs (again, just for testing) :
EDIT: 20 sep, 2023, other possible method without loading 20pipewire.sfs: https://forum.puppylinux.com/viewtopic. ... 178#p99178
EDIT: 17 sep, 2023, NEW 20pipewire.sfs ATTACHMENT AND INFO HERE: https://forum.puppylinux.com/viewtopic. ... 873#p98873
EDIT: 16 sep, 2023 Re-uploaded 20pipewire.sfs, see info; https://forum.puppylinux.com/viewtopic. ... 795#p98795
EDIT: 11 sep, 2023 Re-uploaded 20pipewire.sfs, contains now the proper alsa conf files in /etc, see: https://forum.puppylinux.com/viewtopic. ... 447#p98447
EDIT: 12 sep, 2023 Re-uploaded 20pipewire.sfs, running pipewire is done now from /etc/X11/xinit/xinitrc.d/start_pipewire.sh instead of from ~/.xinitrc, see also https://forum.puppylinux.com/viewtopic. ... 490#p98490
Load at boot by adding it to the same dir as the rootfs sfs.
Main contents are:
- /usr/local/bin/run-as-spot (newest from @jamesbond , modified )
- /root/.xinitrc (modified for to run-as-spot wireplumber , pipewire, and dbus-session (edit; the latter is important too, and the newer run-as-spot supports it))
edit 12 sep, 2023, instead of running from /root/.xinitrc , now from /etc/X11/xinit/xinitrc.d/start_pipewire.sh
- empty file /root/Startup/start_pulseaudio (disables the default pulseaudio start in KLV-Airedale)
And added for convenience the wireplumber pipewire bins and libs (but should better be installed officially with xbps-install wireplumber pipewire edit: and alsa-pipewire)
edit: first test if it works ok can be by running pavucontrol. This should work without having pulseaudio started.

fredx181 wrote: ↑Sun Sep 10, 2023 4:06 pm

edit: first test if it works ok can be by running pavucontrol. This should work without having pulseaudio started.

Well, just when I have a couple of Airedales with remastered and squashed rootfs's going strong, you're giving me a reason boot clean again. Being I do a lot audio work I've been wondering when it would be time to look at migrating to pipewire.

@geo_c Let's try out the SFS on KLV-Airedale-sr5 and RT and see how it flies!

will give it a go on the KLV-Awesome-RT which with I am slowly getting the hang of configuring it. Awesome has endless config possibilities but lua code configuration file.

Spectrwm is text based config file and the simplest to configure well. If it runs well on KLV-Airedale I'll go right in to these with the SFS included and investigate possibly installing the components

geo_c wrote: ↑Sun Sep 10, 2023 11:42 pm

Being I do a lot audio work I've been wondering when it would be time to look at migrating to pipewire.

This migration is super easy once you have Puppy's .xinitrc and run-as-spot or something similar.

As long as you have pipewire-pulse and /etc/alsa/conf.d/{50-pipewire.conf,99-pipewire-default.conf}, this migration should be painless. Applications with native PipeWire support use PipeWire (if that's the default), applications that talk to PulseAudio talk to pipewire-pulse instead, and applications that use the ALSA API directly pass through PipeWire's alsa-lib modules.

pavucontrol and alsamixer "just work", they way they work in an identical system that has PulseAudio with /etc/alsa/conf.d/99-pulse.conf instead of PipeWire.

For Bluetooth support, you need to install libspa-0.2-bluetooth instead of pulseaudio-module-bluetooth. Once you do that, Blueman also "just works": in my experience, Bluetooth audio works much more reliably.

dimkr wrote: ↑Mon Sep 11, 2023 5:47 am

This migration is super easy ... pavucontrol and alsamixer "just work" ... Blueman also "just works" ...

+1

Anyone using HDMI to TV with audio as their monitor setup?

@geo_c, couple months ago, I was visiting with a friend to one of their friends who was a musician before heading out to the clubs. He had an interesting setup.

He was running a Win11 setup with 3 TVs as monitors: 2 of the monitors were via HDMI cables while the 3rd was via usb-c. He had each monitor playing an instrument simultaneously with a different instrument playing on each of the others. This, he had, emulating a 3 instrument band. I found this intriguing and fascinating.

Not sure if this could be accomplished with current knowledge of Linux, but pipewire and wireplumber (graphical) might allow a similar 3 piece band to be achievable.

The world is moving so fast as all of this current stuff is so tremendous as I am starting to feel that I am NOT in the present, but have walked thru a warp into the future...with no way back.

dimkr wrote:

As long as you have pipewire-pulse and /etc/alsa/conf.d/{50-pipewire.conf,99-pipewire-default.conf}, this migration should be painless

Mmm... 50-pipewire.conf,99-pipewire-default.conf are not in the sfs I shared (edit: now does, see EDIT at first post), also checked the contents of packages pipewire and wireplumber, no such conf files.
Don't know if it's a problem, it does work ok for me though on KLV-Airedale, pipewire-pulse is included as a symlink to pipewire in /usr/bin.

fredx181 wrote: ↑Mon Sep 11, 2023 8:03 am

dimkr wrote:

As long as you have pipewire-pulse and /etc/alsa/conf.d/{50-pipewire.conf,99-pipewire-default.conf}, this migration should be painless

Mmm... 50-pipewire.conf,99-pipewire-default.conf are not in the sfs I shared, also checked the contents of packages pipewire and wireplumber, no such conf files.
Don't know if it's a problem, it does work ok for me though on KLV-Airedale, pipewire-pulse is included as a symlink to pipewire in /usr/bin.

/usr/share/examples/pipewire/20-pipewire-pulse.conf is part of pipewire and alsa-pipewire contains these:

/usr/share/alsa/alsa.conf.d/50-pipewire.conf
/usr/share/alsa/alsa.conf.d/99-pipewire-default.conf

Unlike the Debian package, which already has the symlinks under /etc, the void handbook asks you to create them yourself - see https://docs.voidlinux.org/config/media ... eplacement and https://docs.voidlinux.org/config/media ... ntegration.

Re-uploaded 20pipewire.sfs , download at first post
Includes now the contents of package alsa-pipewire and the .conf files in /etc (symlinks as suggested to create, according to the Void documentation), thanks for the info @dimkr !

Clarity wrote: ↑Mon Sep 11, 2023 7:47 am

He was running a Win11 setup with 3 TVs as monitors: 2 of the monitors were via HDMI cables while the 3rd was via usb-c. He had each monitor playing an instrument simultaneously with a different instrument playing on each of the others. This, he had, emulating a 3 instrument band. I found this intriguing and fascinating.

Not sure if this could be accomplished with current knowledge of Linux, but pipewire and wireplumber (graphical) might allow a similar 3 piece band to be achievable.

This is not a problem, it's simply a matter of running multiple monitors. I believe any distro with a fully functioning Xfce desktop and appropriate firmware/drivers can handle the job. The multi-instrument setup is contingent on having specific audio software (for instance Ardour DAW or Bitwig DAW in linux) and the proper hardware to trigger the instrument sounds (a midi keyboard in particular).

I've run virtual instruments using the jack audio server in jackalpup quite easily. There are a good number of jack compatible software packages that work.

@fredx181 I have been able to use the Pipewire SFS in several various KLV-Airedale's and it looks like it works really well in all of them.

Probably will be included in the rootfs for sr6

So since I have a fresh install of KLV-awesome, I suppose I can simply delete the upper_changes, add the pipewire.sfs to the install directory and reboot. No other configuration necessary?

One step further, assuming the files in the sfs are the latest updated files, would it be possible to add it as the top layer over squashed upper_changes in KLV-airdale? It seems any files present on the system already would simply be updated, and those not present would be added.

@geo_c I tried it out on a KLV-Airedale-sr5 and a KLV-Airedale-RT and both with established upper_changes directories by just placing the 20pipewire.sfs into the frugal directory base next to the kernel components and rootfs SFS. Then simply rebooted and the audio worked and when queried reports we're using pipewire.

On both systems I left the upper_changes as is and just put the SFS in place and rebooted and it all works. I don't have Bluetooth on the machine so I can't test Bluetooth functionality so I do not have any of the Bluetooth packages installed.

Next testing it out on KLV-Spectr, KLV-Bspwm and KLV-Awesome, though I think it will work the same on all of them. Having all 4 distro variation's core construction being the same across the KLV's makes most of the configurations for system operations work in the same ways.

As @wiak mentions, being that all of the Kennel Linux's types use the same Firstrib systems and initrd, it makes building different basic versions of KLV for example, very quick. This is what makes it relatively easy to throw together a KLV with alternative window managers and desktop designs.

I just make an ISO that has a basic set up and can boot so someone can quickly join in the fun trying to make good desktops of different philosophies

Re-uploaded 20pipewire.sfs, running pipewire is done now from /etc/X11/xinit/xinitrc.d/start_pipewire.sh instead of from ~/.xinitrc
Download at first post
I thought it would be more convenient, e.g. for exchange with other window-managers that the code for to run pipewire is in separate script (not in ~/.xinitrc , so left it out in the sfs).
But note: this assumes that /root/.xinitrc contains:

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

But I guess this is often the case in KL systems.
EDIT: Btw, first I tried to run "start_pipewire.sh" from /root/Startup , but didn't work, don't know why.

@fredx181 I can't get audio to work when logged in as spot and with the pipewire SFS loaded. As root pipewire is working really well but to get audio to work when logged in as spot, I had to start pulseaudio. Which only started after having to adjust permissions and other fiddling around which I am not really sure what I did and in what order, that got audio to go as spot.

We'll have to look at getting the pipewire server on the user spot desktop.

rockedge wrote: ↑Wed Sep 13, 2023 3:32 am

@fredx181 I can't get audio to work when logged in as spot and with the pipewire SFS loaded. As root pipewire is working really well but to get audio to work when logged in as spot, I had to start pulseaudio. Which only started after having to adjust permissions and other fiddling around which I am not really sure what I did and in what order, that got audio to go as spot.

We'll have to look at getting the pipewire server on the user spot desktop.

This shouldn't be a very difficult task.

Recommend a path to change from noveau to nvidia. I have a 10yo i5 intel desktop with a geoforce 250 adapter going HDMI to TV as monitor with expected audio over the same connection.

Thanks in advance for guidance

rockedge wrote: ↑Wed Sep 13, 2023 3:32 am

@fredx181 I can't get audio to work when logged in as spot and with the pipewire SFS loaded. As root pipewire is working really well but to get audio to work when logged in as spot, I had to start pulseaudio. Which only started after having to adjust permissions and other fiddling around which I am not really sure what I did and in what order, that got audio to go as spot.

We'll have to look at getting the pipewire server on the user spot desktop.

Yes, I just tried too to make it work logged in as spot, but no success yet.
Had a look at https://docs.voidlinux.org/config/media ... eplacement but this method may conflict with the "root / run-as-spot" setup.
Won't be easy, I guess.

@fredx181 This is the Puppy trick:

1. spot has its own session bus - https://github.com/puppylinux-woof-CE/w ... initrc#L48
2. Applications running as spot talk to spot's session bus instead of talking to root's one - https://github.com/puppylinux-woof-CE/w ... s-spot#L95
3. pipewire, pipewire-pulse and wireplumber run as spot - https://github.com/puppylinux-woof-CE/w ... initrc#L55
4. root talks to spot's instance of pipewire - https://github.com/puppylinux-woof-CE/w ... initrc#L68

This setup might not won't work with systemd, because the session bus works differently and you're not supposed to have more than one session bus in this PAM session.

@dimkr @fredx181 I am doing the same and I am getting sound in the spot desktop but no pavucontrol since it won't connect.

I seem to be missing the 20-pipewire-pulse.conf. There is a broken symlink for it though.

Didn't try the audio right way on the spot desktop since I can see pavucontrol couldn't connect to pipewire-pulse. Then going through troubleshooting steps I just tried a YouTube video in Firefox and the audio worked fine. Volume control via Firefox and YouTube volume slider.

I can see all the pipewire components running as spot in htop. I can not so far get pavucontrol to work on the spot desktop. Works great on the root desktop.

I threw this sfs above a few squashed upper_changes and below my current upper_changes.

Audio seems to be working fine, pulse audio works as normal. Haven't tested with a spot application yet.

I'm just not sure how to really test pipewire. There are a couple desktop files that seem to start pipewire and pipewire-pulse, but no pipewire gui or anything of that nature.

So is pipewire's presence mainly to accomodate pipe-wire compatible applications? And then most control is done through pulseaudio-volume-control?

ADDENDUM: My reading seems to suggest that pipewire is mostly a backend server, and I'm trying to figure out what the actual advantage is, other than blue-tooth compatibility.

It seems that to do things like use mutli-channel soundcards, the pulse-audio "pro-audio" profile needs to be chosen from pavucontrol, and then additional configs might be needed in the pipewire config files.

I'll do some testing this week using various multi-channel audio interfaces, and see what I figure out.

Audio seems to be working great in general though using parole media player and browsers.

Pro Audio is jack. There should be a choice for regular analog stereo or hdmi stereo as applicable in the pavucontrol app. Both should work and you should be able to switch between them on the fly, or at least I can in Debian Dog. The old alsa sound controls should work too.

geo_c wrote: ↑Wed Sep 13, 2023 3:08 pm

ADDENDUM: My reading seems to suggest that pipewire is mostly a backend server, and I'm trying to figure out what the actual advantage is, other than blue-tooth compatibility.

It can replace PulseAudio (via pipewire-pulse) and JACK (via pipewire-jack) and works even with applications that use plain ALSA API (through pipewire-alsa). In addition to its "single solution" nature, it improves Bluetooth audio a lot, reduces audio latency (by using RTKit to run with a realtime scheduling policy), provides video sharing capabilities under both X and Wayland (together with portals; without PipeWire, screen sharing won't work under Wayland) and integrates with Flatpak.

EDIT: The latest 20pipewire.sfs (download at first post) has fixes and everything included now, so forget about the following.

dimkr wrote: ↑Wed Sep 13, 2023 11:42 am

@fredx181 This is the Puppy trick:

1. spot has its own session bus - https://github.com/puppylinux-woof-CE/w ... initrc#L48
2. Applications running as spot talk to spot's session bus instead of talking to root's one - https://github.com/puppylinux-woof-CE/w ... s-spot#L95
3. pipewire, pipewire-pulse and wireplumber run as spot - https://github.com/puppylinux-woof-CE/w ... initrc#L55
4. root talks to spot's instance of pipewire - https://github.com/puppylinux-woof-CE/w ... initrc#L68

This setup might not won't work with systemd, because the session bus works differently and you're not supposed to have more than one session bus in this PAM session.

Thanks, but we have that already working well (for when logged in as root), as I said taken from BookwormPup64.
Issue now it's about when logged in as regular user (spot or weedog, both included in KLV) but got it working now, inspired by the method (i.e. with session-bus, runtime in /tmp etc...).

@all Please test.
As addition to the SFS (from first post), how to run the pipewire server when logged in as spot or weedog in KLV-Airedale:

- extract pipewire-scripts.tar.gz in /usr/local/bin/ (contains pipewire-spot.sh and pipewire-weedog.sh)

- edit /home/spot/.xinitrc , add . /usr/local/bin/pipewire-spot.sh before last line exec xfce4-session (note the . before the path, should be 'sourced')
- edit /home/weedog/.xinitrc , add . /usr/local/bin/pipewire-weedog.sh before last line exec xfce4-session

This works OK for me. Not sure though if the official Void method (system-wide pipewire start ) is better.
EDIT: The scripts contain some 'sudo' commands, luckily the users spot and weedog require no password when using sudo, I guess that's intended. (less secure though, but I'm personally fine with it)

I certainly understand pipewire benefits having seen it and used in other distros.

I am especially hopeful for the graphical ability to SEE the connections via Pipewire making is simpler to resolve/understand what is talking to who.

I will wait for the upcoming KLs that have this integrated.

Seem that I am one of only a few who use these old PCs connections via HDMI (to TV) for audio/video services. I use TVs because they are cheap and provide a much larger viewing area for my old eyes making it so easy to see all the active app clearly.

Newer TVs are now about to upgrade ALL cheap models to 120Hz versus the normal 60.

I am seeing issues when running KL where video is fine, but having issues with locating audio in CURRENT KLs. What should be happening is that the distro when seeing HDMI use will 'automatically' direct audio to the HDMI stream (I think most people know HDMI bring video AND audio together). But, so far, few in puppyland have this operational.

So, I will delay my questions for guidance until KLs integrate the technology into upcoming ISOs.

@fredx181 Nice!

Now pipewire, pipewire-pulse working with volume control in both root and spot desktops.

Next I will be integrating it into the KLV-Spectr-RT system.

rockedge wrote: ↑Thu Sep 14, 2023 12:09 am

@fredx181 Nice!

Now pipewire, pipewire-pulse working with volume control in both root and spot desktops.

Next I will be integrating it into the KLV-Spectr-RT system.

Doing more investigating, don't really like the scripts that start pipewire for logged in as spot and weedog (although works for me), will try to avoid the need of sudo in the scripts, probably can make it work for when logged in as spot without the sudo-ing, for weedog user I think it's another story.
Problem is that when running as root and then logout, then the pipewire and pipewire-pulse processes are still running (don't know why ), so need to be killed IMO when logging in as another user.

Couple schools of thought.

School 1: Pipewire is a system-wide function available to all users running all the time no matter the user. Same system config and expected use across the board; and is setup by root admin. For example if one tailors his system to 'say' Hello World at login.

School 2: Pipewire configures differently for each/every separate user. Thus this would require to drop Pipewire at logout and institute anew base function for next login...no matter the user. This denotes a user function to design/redesign after login.

These are just thoughts, as there may be additionals. Not sure which path offers proper expected usage from the developer/user standpoint.

Just ideas..

My latest release of QuickPup64 has full pipewire support, it uses pipewire on root instead of separate pipewire process, I just share pipewire via TCP (pulseaudio port was blocked on firewall) and modify the run-as-spot script. To manage pipewire routes, use helvum

#!/bin/ash
# generic wrapper to run as ${XUSER} (when currently running as root)
# (C) James Budiono 2012, 2017
# License: GPL version 3 or later
#

#set -x

XUSER=spot

case $0 in *run-as|*run-as-user)
	if ! [ "$1" ] ; then
		echo "$0: Specify user"
		exit 1
	fi
	XUSER=$1
	shift
esac

CWD=$PWD
CMD=''
while [ "$1" ]; do
	CMD="$CMD \"$1\""
	shift
done

[ "$CMD" ] || exit

USER_HOME=$(awk -F: '$1=="'"${XUSER}"'" {print $6}' /etc/passwd)
if ! [ "${USER_HOME}" ] ; then
	echo "$0 ERROR: could not HOME dir for user $XUSER"
	exit 1
fi
CURDIR=$PWD

if [ $(id -u) -eq 0 ]; then
	[ $XAUTHORITY ] && cp $XAUTHORITY ${USER_HOME}/.Xauthority 2>/dev/null
	touch ${USER_HOME}/.Xauthority
	export XAUTHORITY=${USER_HOME}/.Xauthority

	# replace all occurences of /root in XDG_* with /home/spot, because we don't
	# run a login shell and source /etc/profile.d/*
	OLD_HOME="$HOME"
	while IFS='=' read NAME VAL; do
		case "$NAME" in
		XDG_*) export $NAME="`echo "$VAL" | sed -e s~^$OLD_HOME~$USER_HOME~ -e s~:$OLD_HOME~:$USER_HOME~g`" ;;
		esac
	done << EOF # hack for old busybox, which doesn't understand <() and <<<
`env`
EOF

	export XDG_CONFIG_HOME=${USER_HOME}/.config
	export XDG_CACHE_HOME=${USER_HOME}/.cache
	export XDG_DATA_HOME=${USER_HOME}/.local/share

	for i in ${XDG_CONFIG_HOME} ${XDG_CACHE_HOME} ${XDG_DATA_HOME}
	do
		if ! [ -d $i ] ; then
			mkdir -p $i
			chown ${XUSER} $i
		fi
	done

	if [ "${XDG_RUNTIME_DIR}" ] ; then
		export XDG_RUNTIME_DIR=/tmp/runtime-${XUSER}
		if [ ! -d ${XDG_RUNTIME_DIR} ] ; then
			mkdir -p ${XDG_RUNTIME_DIR}
			chmod 0700 ${XDG_RUNTIME_DIR}
			chown ${XUSER} ${XDG_RUNTIME_DIR}
		fi
	fi

	#if [ -s /tmp/.spot-session-bus ]; then
	#	. /tmp/.spot-session-bus
	#	export DBUS_SESSION_BUS_ADDRESS
	#	export DBUS_SESSION_BUS_PID
	#fi

	# close all file descriptors except std{in,out,err}, in case one of
	# them points to a file under /root
	for FD in /proc/self/fd/*; do
		FD="${FD##*/}"
		[ $FD -gt 2 ] && eval "exec ${FD}<&-"
	done
	
	exec su ${XUSER} -s /bin/ash -c '
# try to switch to original directory, unless it is /root
if [ "'"$CURDIR"'" = /root ]; then
	cd "'"$USER_HOME"'"
else
	cd "'"$CURDIR"'"
fi

 export DBUS_SESSION_BUS_ADDRESS='${DBUS_SESSION_BUS_ADDRESS}'
 export PULSE_SERVER="tcp:127.0.0.1:4713"
 
 exec '"$CMD"'
 
'
else
	exec ash -c "exec $CMD"
fi

### END ###