- This topic has 16 replies, 7 voices, and was last updated Jan 18-3:33 pm by Brian Masinick.
-
Posts
-
Toposoft
Currently for activating pipewire in my system I have to go to the Control Center, and use the Pipewire toggle from the “Hardware” section, but I would want it activated by default. I am using XFCE, so I think I just could add the “toggle-pipewire” commmand to the autostart in XFCE Control Center, but I’m asking here just in case I’m missing something. Will just the command “toggle-pipewire” do the trick or I need to add something else to it?
EDIT: SOLVED! I just went to the XFCE configuration center, clicked on Session and Startup, went to the Automatic start of applications tab, and just a new app with the command “pipeline”. It worked. I asked because I assumed that the command “toggle-pipewire” did something else that was necessary or something like that. But no, it was as simple as just starting pipewire directly.
- This topic was modified 8 months, 1 week ago by Toposoft.
Robin
I have to go to the Control Center, and use the Pipewire toggle from the “Hardware” section,
Yes, in antiX this pipewire/alsa selection should survive reboots and relogins, since the pipewire-toggle from antiX Control Centre writes an entry into ~/.desktop-session/startup, which is in antiX the default way to execute something at login time. Please check your install whether it respects this file, or whether your XFCE mod has broken something. You may miss some more antiX startup defaults then.
Windows is like a submarine. Open a window and serious problems will start.
olsztyn
Currently for activating pipewire in my system I have to go to the Control Center, and use the Pipewire toggle from the “Hardware” section, but I would want it activated by default. I am using XFCE, so I think I just could add the “toggle-pipewire” commmand to the autostart in XFCE Control Center,
In addition to what @Robin suggests you might want to check another option:
Since you run XFCE by default, you might as well specify pipewire in your XFCE autostart, as you want it to start by default. I used to use XFCE in the interim, but pretty sure this is the way on XFCE. This is the way I am using on my antiX LXQT now as well.- This reply was modified 8 months, 1 week ago by olsztyn.
- This reply was modified 8 months, 1 week ago by olsztyn.
- This reply was modified 8 months, 1 week ago by olsztyn.
Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersHi @Robin
Yes, you are right, .desktop-session files are not being respected by XFCE, but I’m okay with that, by now I don’t need nothing that gets autostarted there, fortunalely. Thank you.and @olsztyn I followed your advice and just autostarted the pipewire command from XFCE autostart, Which I configured from control center. Works perfectly. My doubts were solved and I’ll edit my post. Thank you.
- This reply was modified 8 months, 1 week ago by Toposoft.
it was as simple as just starting pipewire directly.
The toggle_pipewire tool cares for handling some symlinks in /usr/share/alsa/alsa.conf.d additionally, which prevent plain ALSA from proper working when present, and prevent pipewire from proper working if not present. Additionally it handles the change of the mixer (alsamixer/pavucontrol) in volumeicon. Not sure whether you need that to observe in XFCE as well.
Windows is like a submarine. Open a window and serious problems will start.
ProwlerGr
User service support should be coming with antiX-26 for each of the supported modern inits.
Every init comes with the rc-local user service installed by default.
This user service allows users to create their own scripts in their home folder (giving them the .start extension) & they will be launched at their login regardless of window or session manager or desktop environmnent (as long as they are executable).Eg
Runitecho "#!/bin/sh pipewire & " > ~/.runit/rc-local/pipewire-toggle.start && chmod +x ~/.runit/rc-local/pipewire-toggle.starts6-rc
echo "#!/bin/sh pipewire & " > ~/.s6-rc/scripts/rc-local/pipewire-toggle.start && chmod +x ~/.s6-rc/scripts/rc-local/pipewire-toggle.starts6-66
echo "#!/bin/sh pipewire & " > ~/.66/script/rc-local/pipewire-toggle.start && chmod +x ~/.66/script/rc-local/pipewire-toggle.startdinit
echo "#!/bin/sh pipewire & " > ~/.dinit.d/scripts/rc-local/pipewire-toggle.start && chmod +x ~/.dinit.d/script/rc-local/pipewire-toggle.start
anticapitalista
If you are using antiX-full,pipewire should be default regardless of which desktop is used.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
If you are using antiX-full,pipewire should be default regardless of which desktop is used.
Except for the 32 bit versions. On all 32 bit antiX plain ALSA is default, and the user can enable pipewire in Control Centre, based on what results he experiences from his hardware. Reason for the difference to 64 bit is: There are many 32 bit devices, which can’t stem pipewire, while there are also many 32 bit devices, which can handle it easily all the same like the 64 bit devices.
Windows is like a submarine. Open a window and serious problems will start.
User service support should be coming with antiX-26 for each of the supported modern inits.
Every init comes with the rc-local user service installed by default.
This user service allows users to create their own scripts in their home folder (giving them the .start extension) & they will be launched at their login regardless of window or session manager or desktop environmnent (as long as they are executable).This looks to me a great idea. If I understand correctly it can be specified once, in one place, as a user service and no need to define it in autostart of each desktop or WM. So, if someone is running XFCE, LXQT and Openbox, then all of them will inherit such e.g. pipewire already started ahead of DE launch…
Hopefully that is the way it works…Edit:
This becomes even more interesting… I just logged-in on VT2 and looks like RC-Local was triggered upon login. This means that logging-in does not have to be done through login manager, such as lightdm, logging-in on VT triggers this service as well…Edit2:
Now, when I am learning a little bit more about rc-local service, I came to thinking it might resolve a long standing issue with pipewire an volumeicon for those who use icewm.
Namely there are three components that must be started for pipewire to actually work and volumeicon to appear and work on icewm:
– pipewire
– pipewire-pulse
– wireplumber
With prior antiX icewm implementations volumeicon must wait some time until wireplumber has started and initialized. It does not know how much time, so users had a ‘sleep’ before volumeicon. Sleep amount used was typicaally 5 seconds, but not guaraanteed. Some users had 10.
Since rc-local executes commands in sequence, would such sequence ensure that volumeicon will always start?
– pipewire
– wireplumber
– pipewire-pulse
– volumeiconDoes sequence of execution of commands in rc-local ensures that the next command is started only after the previous command is executed successfully and related process started? This would be somewhat equivalent to ‘depend on’ or ‘wait on’ clauses in service definition…
- This reply was modified 8 months, 1 week ago by olsztyn.
- This reply was modified 8 months, 1 week ago by olsztyn.
Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersSince rc-local executes commands in sequence, would such sequence ensure that volumeicon will always start?
– pipewire
– wireplumber
– pipewire-pulse
– volumeiconThe rc-local is just a convenience user service to start scripts in sequential order (unsupervised) – nothing more.
What you are describing could potentially be achievable by native user-services for pipewire, wireplumber, pipewire-pulse & volumeicon for each init that offer dependency resolution (66, s6-rc, dinit).
Runit is a bit of a different story as it doesn’t handle dependencies natively, but a pseudo oneshot could be created that runs as a daemon to detect pipewire, wireplumber & pipewire-pulse, & then launch volumeicon with its finish script.What you are describing could potentially be achievable by native user-services for pipewire, wireplumber, pipewire-pulse & volumeicon for each init that offer dependency resolution (66, s6-rc, dinit).
Can these handle also the removal and creation of the proper symlinks in /etc/alsa/conf.d, and also fix the needed pipewire/plain-ALSA specific settings for e.g. xmms and cmus (and possible other programs in future) ? Otherwise users might get a poor experience, finding things not working as expected. Please check what additional tasks /usr/local/bin/toggle_pipewire executes, which represents basically what is needed to ensure that either pipewire or plain ALSA works flawlessly. When now moving the pipewire startup sequence from ~/desktop-session/startup to all the individual init systems, how this can be handled and kept in sync?
Windows is like a submarine. Open a window and serious problems will start.
Can these handle also the removal and creation of the proper symlinks in /etc/alsa/conf.d, and also fix the needed pipewire/plain-ALSA specific settings for e.g. xmms and cmus (and possible other programs in future) ?
You’d still need a system (root) service to handle any symlinking in /etc/alsa/conf.d, user services can only be run with user permissions.
When now moving the pipewire startup sequence from ~/desktop-session/startup to all the individual init systems, how this can be handled and kept in sync?
To be clear the current antiX infrastructure is not being being affected or changed for antiX-26.
Whatever was being handled by ~/desktop-session/startup is still being handled by that startup script with no immediate plans for this to change AFAIK (I am second-guessing here – feel free to correct me on this @anticapitalista)We have just opted to plant the infrastructure to introduce user services into antiX, a few indicative user services come packaged (eg dbus spice-vdagent) to showcase that our init infrastructure offers everything a modern distro may require.
We are just planting a seed here, the future will tell if the seed will flourish or rot in the ground.
Runit is a bit of a different story as it doesn’t handle dependencies natively, but a pseudo oneshot could be created that runs as a daemon to detect pipewire, wireplumber & pipewire-pulse, & then launch volumeicon with its finish script.
Looks to me that e.g. dinit seems more sophisticated than runit in dependency resolution, such as ‘depends on’ or ‘wait for’ clauses available in dinit.
I remember that volumeicon appearance on icewm used to be quite a headache for many users and introducing ‘sleep 5’ before volumeicon invocation was a poor solution, just guessing that in 5 seconds after starting, the wireplumber should be up. Handling such dependency by a service would be more elegant, but requires additional work to develop.
I am curious how DE’s such as XFCE or LXQT solve pipewire/wireplumber readines, because their own volume icon seems to appear on their panels immediately and volume and sound works right away, no 5 seconds wait needed, although running on runit or another init such as dinit and no dedicated service has been developed for antiX…- This reply was modified 8 months, 1 week ago by olsztyn.
- This reply was modified 8 months, 1 week ago by olsztyn.
- This reply was modified 8 months, 1 week ago by olsztyn.
Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parametersanticapitalista
On my laptop I remove the 5 second wait for volumeicon and have no issues.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
On my laptop I remove the 5 second wait for volumeicon and have no issues.
Indeed, behavior is dependent on how fast the hardware is, I think. If the wireplumber initiates fast enough, before the volumeicon then no wait is necessary.
Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters
- You must be logged in to reply to this topic.