- This topic has 38 replies, 12 voices, and was last updated Jul 7-9:47 am by anti-apXos.
-
Posts
-
anti-apXos
The current Pipewire implementation on antiX is a bit inconsistent. There are two pipewire-alsa conf files linked at the system level (in /etc/alsa/conf.d), but starting Pipewire is user-specific (a line in $HOME/.desktop-session/startup). This leads to potential issues, especially on systems with multiple users.
Example: user Sammy toggles Pipewire off from Control Centre, which comments out pipewire in his desktop-session startup and also remove the pipewire-alsa symlinks from /etc at the system level. Now when user Deborah logs in, pipewire still starts from her desktop-session startup file, but the needed pipewire-alsa conf files have been removed from /etc, so she is left with an incomplete Pipewire instance without ALSA connections. If Deborah then uses the Pipewire toggle in Control Centre to get it working correctly, when Sammy logs in again the pipewire-alsa conf files are back but his desktop-session startup file still doesn’t try to start Pipewire, so now he has a non-working ALSA audio system (“Host is down.”). And so on, back and forth, unless both/all users on the system coordinate their configurations.
There’s a couple potential solutions to this, but I think the best is to just put the pipewire-alsa symlinks in the user’s $HOME directory (in $HOME/.config/alsa/asoundrc) instead of in /etc. This would make enabling/disabling Pipewire a strictly per-user change with no effect on other users of the system. As a bonus, the Pipewire toggle script would also no longer need gksu/sudo authentication since no system files need to be changed.
I believe that the only modifications needed for this should be an update to the toggle_pipewire script and repackaging the pipewire-alsa package so that it includes the conf symlinks in /etc/skel/.config/alsa/asoundrc/ instead of in /etc/alsa/conf.d/. Even the default “demo” user on the live USB gets their initial config from /etc/skel/, right?
I’m attaching an updated toggle_pipewire script for anyone interested in testing this. I’ve been using Pipewire this way for quite a while and there really should be no issues with it as far as I understand. It’s just using an alternate location from the ALSA configs hierarchy.
The attached testing script will use gksu to ask for authentication only in the case that it needs to remove the pipewire-alsa symlinks from the system-wide location in /etc/alsa/conf.d, otherwise it doesn’t. After testing, if you want to go back to using the original pipewire-alsa location in /etc, disable Pipewire using this script and then re-enable Pipewire with the existing toggle in Control Centre and everything will be as it was.
- This topic was modified 1 year, 10 months ago by anti-apXos.
"--"
Robin
@anti-apXos Many thanks! Your approach sounds very reasonable. This is a next step towards true multi user capability of antiX 🙂
Looking into the script code I wonder why you have deactivated the reload of alsa configuration. From my former experiments with alsa some years ago an alsa restart is needed to make it work again after whatever alsa config changes.
The former script version had this line:
alsactl -F nrestore
Is there a reason why you have removed this?Even the default “demo” user on the live USB gets their initial config from /etc/skel/, right?
Yes, you are right.
And then, in my perception the former GUI (right side, see screenshot) was way more straightforward than your modification (left side), and very well designed by PPC. Just one lever switch, which turns from green to red (or vice versa) when clicked is enough for everybody to understand what here can be done. And then a button labeled “Done” for leaving the toggle. Clean and simple to use. If user needs some more info, there is a tooltip when hovering the mouse over the switch. Maybe we should add “Click here to switch” to the existing explanation in that very tooltip. But please don’t do such a crowded window, in which user has to read tons of text messages first. I guess you’d never design a light switch in your room that way. 🙂 So why here? And please note, there is already many information given in the tooltips of current antiX control centre (Section hardware), where all the audio controls are centralised. Most of the basics about the additional pipewire layer you’ll find explained in this place already, so it will be redundant if opening the toggle window then.
Attachments:
Windows is like a submarine. Open a window and serious problems will start.
The former script version had this line:
alsactl -F nrestore
Is there a reason why you have removed this?Because it was not necessary based on my testing. Also, depending on wha’s set in the asound.state, doing a restore may reset jack states that were changed while Pipewire was active.
If testing shows that it actually is better to do an init or restore, it can be done, but I thought it best to find that out through testing than to do unnecessary stuff just because.
I guess you’d never design a light switch in your room that way. 🙂 So why here?
Because I have a lifetime of experience with light switches and what they do, but I didn’t think the same was true for Pipewire, so some explanation of what it is or why you might want to enable or disable it seemed like it would be useful.
I don’t think the description I wrote is very good actually and I did hope someone would improve it. Though, personally, I don’t much like the idea of cramming so much into big wordy tooltips.
However, the script I posted is just a demonstration. It would be up to someone else to decide how to actually implement it for antiX. I have no plans to sign up for or do anything with gitlab myself.
"--"
Xunzi_23
anti-apXos wrote
I think the best is to just put the pipewire-alsa symlinks in the user’s $HOME directory (in $HOME/.config/alsa/asoundrc) instead of in /etc. This would make enabling/disabling Pipewire a strictly per-user change with no effect on other users of the system.If I read this correctly that is not a simplification, in a family settings would have to be made for each individual to avoid no sound for some.
A switch must provide expected sound output for each added user included those added at a later date.
Not a criticism, life is often more complicated than we think. Below is probably unknown to persons in warmer sunny areas.
Light switches are often not just on off anymore :-). For a long time we had dimmers. In comes the new world.
The light switch in my workroom allows dimming and changing LED light hue from bright sunny day 6500 to an automagic slow pre sleep dimming changing hue similar to a setting sun
then turning off. It has remote control and like therapy lights (it is same full spectrum) really helps against the common depressed feeling during grey dark northern winter.If I read this correctly that is not a simplification, in a family settings would have to be made for each individual to avoid no sound for some.
A switch must provide expected sound output for each added user included those added at a later date.
This is exactly the problem that can happen on antiX currently and that this suggestion is intended to fix.
If one user toggles Pipewire from Control Centre, then any new users created after that will have a broken Pipewire instance since the desktop-session startup file they start with will still have the default, but the files available in /etc/alsa/conf.d won’t match anymore.
Sorry if my original explanation/example wasn’t clear enough. Or if it still isn’t.
Have other people with multiple user accounts really not run into this issue? I encountered it almost immediately when I started using antiX-23 over a year ago and shortly after that I found this solution, which I’ve been using ever since.
Putting the pipewire-alsa conf files into /etc/skel, where the default desktop-session startup script also already is, means that newly created users will always have a working default Pipewire/ALSA setup no matter what other users have done.
"--"
@Robin Since you seem to be currently the one working on Control Centre, I’ll report to you that I just noticed a bit of a bug in Control Centre’s toggle_pipewire entry.
I’m not sure why, but starts the script with
bash toggle_pipewirebut the problem is that bash first looks for the specified script in the present working directory before trying $PATH. So if you happen to have a file called “toggle_pipewire” in your $HOME dir, it will run (or try to run) that instead of the intended script in /usr/local/bin. I guess the launch line should be changed to
bash $togglepipewire_prog@Everyone This means if you test the script from my first post, you should extract it to somewhere other than your home directory, or else the Pipewire toggle option in Control Centre will start it instead of the original script.
"--"
Hi @anti-apXos,
I encountered it almost immediately when I started using antiX-23 over a year ago and shortly after that I found this solution, which I’ve been using ever since.
Yes. This is why I had said above: „This is a next step towards true multi user capability of antiX”. Same issue with localisation of antiX System Menu. If one user sets his environment to another language than other users, the menu will be changed for all other users when he installs a program (due to the apt-hook for desktop-menu) or refreshes his menu. I tried to address that already some years ago, but the fix I had sent to Dave didn’t make it into current antiX until now. But meanwhile I have an idea how to overcome the problem, that the menu refresh takes more time then, since it must be executed for all users separately then instead once for all together. I’m up to send my improved proposal to Dave soon.
I’ll report to you that I just noticed a bit of a bug in Control Centre’s toggle_pipewire entry.
Many thanks for spotting that. I’ll fix it as soon as possible.
Windows is like a submarine. Open a window and serious problems will start.
Yeah, I’ve noticed problems like that with the menu-applications list, too. In fact, I’ve wondered why desktop-menu isn’t used to generate the menu on-the-fly instead of using pre-made files that require refreshing and lead to these issues.
In IceWM, you can just use
menuprog Applications "app-launcher" desktop-menuand the submenu will be generated fresh each time you open it. desktop-menu seems to have been designed with this in mind, but maybe the slight pause while the menu generates was considered too much?
In the end, I’ve always ended up maintaining my own applications menu and modifying the text file when I install something new if I want it to be in the menu. It may seem primitive, but it certainly gives the most control over what appears and how it’s organized.
"--"
blur13
I personally dislike toggles like the one on the right in Robins post. How are you supposed to tell what the initial state is? Does “green” mean that it is currently activated? Or does it mean that clicking the toggle will activate it?
One interpretation would be: I click the toggle and it turns from green to red. That means that I have activated pipewire, and the toggle is now red. That means that if I click the toggle again I will deactivate pipewire, and the toggle turns to green.
someone else took the time to explain this a lot better:
PPC
Hi, everyone
It seems that every time I take a few days off to be with my daughter, I miss important stuff here in the forum…
1- Thanks for noticing that the “Pipewire toggle” affected all users, not just the user that toggles it on/off. Being used to be the single user on my computers makes it harder for me to think that in fact, the OS should be built with multi-user support in mind… But I did not implement Pipewire in antiX, I just came up with the idea that a toggle should be available, so users that prefere ALSA or need ALSA for some reason can easily switch to it, so I worked with Pipewire implementation that we got, not thinking to alter it
2- How the toggle GUI looks… [long sigh]…
For years I’ve been fighting to try to make antiX more user friendly. I came up with the Firewall toggle, and tried to make as simple to use as possible. Even so, at least one user had problems with it… So I tried to come up with something even simpler… So why not a simple toggle button, like most tech using humans are used to, in Smartphones and Web pages?
In this case, there’s not complex “gradient” needs. It’s either on or it’s off. There’s no half way. So mimicking a simple light switch or the toggles used in smartphones and some web pages would be ideal… I tried to improve the design: On my phone, all configurations have the “Option name”, followed by the “switch”. It came to me that it make no sense: to “enable” the option, the switch had to be moved away from the “Option name”. That’s counter intuitive: light switches have On/Off indications. If you move the switch to the “On” option, it does what it says: turns the light “on”… So I designed the GUI that way: move the switch to the side of the “Option name”, to enable it. Move the switch away from the “Option name” to disable it.
OK… But let’s make it simpler: color code it: in a side walk, the “Green” sign means you can cross the street, that the crosswalk can be used…
So I color coded the switch: “Green”, the option is “ON”, “Red”, the option is “Off”.
Yes… I should have made it even more completely clear: the Name of the option should change to reflect it’s state “Pipewire is currently on”/ “Pipewire is currently off”. But hey… I’m just one guy, I can’t think of everything…That said, people that think that a simple switch, like currently exists is not easy to understand (hum… it may be a bit harder, if you are color blind, sorry), but suffer a lot, when using smartphones or some web pages options, because I just tried to implement what’s used there adapting it to make even more sense: just switch to the side that has the option name to enable it!!!
As Robin commented, the Control Entry icon that allows access to the Pipewire Toggle script is already very well documented. Besides, it’s the kind of stuff that is too technical for the casual user. Placing a large explanation on it’s window will probably be useless, if the explanation provided in the Control Centre main window was not enough for the user…
I thought I made a general use UI that everyone used to modern computing could use. I was clearly wrong.
My advice, that no one asked for: do change were Pipewire places the config files and change the script accordingly… On the GUI of the script would be to keep it and make the text change to display “Pipewire is currently on”/ “Pipewire is currently off”. If you really, really want to explain how a simple switch works, feel free to add a line stating “Press the switch bellow to change the Pipewire status”. You never know. Some people do no realize they are supposed to press the switch. I’m not being ironic: that happened before, the user commented on that, that, on the first try, they did not realize they were supposed to click anywhere, they just thought launching the script would toggle on/off Pipewire, that the window was merely informative (and that is a reasonable expectation).But I’m just a guy, I don’t run the show. anticapitalista aproves the changes around here.
P.
- This reply was modified 1 year, 10 months ago by PPC.
richtea
Best get rid of pipewire altogether; I do not see any benefit in running it.
I don't care if people hate my guts; I assume most of them do. The important question is whether they are in a position to do anything about it.
William S. Burroughsstevesr0
I am the only person using the computers in my home, so I think of them as “single user” hardware. Obviously, if I change from ordinary user to root login, that may be considered two users. But root doesn’t have a home setup, so I suspect that if root wanted to use pipewire, she/he/it could without the (same) problem that two non-root users experience?
Best get rid of pipewire altogether
Like I said:
anticapitalista aproves the changes around here.
I do not see any benefit in running it.
Well, the fact that you don’t see any benefit in running Pipewire and want it gone, does not mean that there are no benefits. If you just use antiX as is, out of the box, with the pre-installed web browser, and that works for you, you have the extra work of doing half a dozen of clicks to disable it and live happily ever after just running ALSA… If you want to use some programs,
for example Firefox (the non-ESR version) or any browser based on it(EDIT: “fact” that I’ll try to confirm when next to my antiX 23.x computer) and you want to have sound out of the box… Then the fastest way to do it (and have audio working) without manually editing .desktop files or launching the browser from the terminal, would be using Pipewire.
If you want to use sound via Bluetooth, you probably require something more evolved than simple ALSA.
If you want audio on some games, emulators, etc, you require something more than ALSA or… trying to manually launch that program with apulse and cross your fingers and hope that it will work (spoiler: it does NOT always work).
Including Pipewire installed, configured and enabled by default in antiX Full, does make sure that users can run all software with sound (and also via Bluetooth, if they so wish).EDIT: the forum sometimes messes up who is being quoted, so I added a note to my quote above…
P.
- This reply was modified 1 year, 10 months ago by PPC.
- This reply was modified 1 year, 10 months ago by PPC.
- This reply was modified 1 year, 10 months ago by PPC.
My advice, that no one asked for: do change were Pipewire places the config files and change the script accordingly…On the GUI of the script would be to keep it
The whole reason for making this post and providing a script for testing was to get anyone and everyone’s feedback on how this suggestion works or should work, certainly including yours.
As for keeping the current GUI, I should mention that I initially tried to just change the paths and remove gksudo from the current script, but that minimal change broke something and the script began leaving behind stray bash processes even after it had been closed. I did try pretty hard to figure out why that was happening, it seemed to be something to do with the way the script calls itself, but I just couldn’t figure it out. So I ended up adapting a separate script that I had already been using instead.
Maybe you can figure out what was causing those bash processes, though, since you’re more familiar with the original script.
If you really, really want to explain how a simple switch works, feel free to add a line stating “Press the switch bellow to change the Pipewire status”.
The information I was trying convey with the description I included was not so much *how* to turn Pipewire on or off, but why. There’s no description anywhere in Control Centre that I can see of what Pipewire actually does, just that it can be turned off/on using this switch.
It’s like the most classic technological obsurity meme to have a program with such an uninformitive (and downright nonsensical) name as “pipewire” and then just provide a switch to turn that thing off with no explanation of what it does. I would almost think it’s a joke or something if I didn’t know better.
Obviously, what Pipewire does is documented elsewhere, though, and maybe the assumption should be that people can do their own research. That probably is a good policy.
- This reply was modified 1 year, 10 months ago by anti-apXos.
"--"
Dear anti-apXos – what I meant about “My advice, that no one asked for” was in the sense that I did not test the script (on my work computer I’m still using antiX 22.X) and I was just making generic observations about what is being suggested.
As you can tell I was particularly stressed out by some people not liking something I hoped would be perfectly understandable (since the “toggle GUI” uses what is currently the default way to enable or disable options on most UI’s, correcting what I consider mistakes done on those UI’s)… but that’s my problem, sorry if I reacted too hard to what are useful criticisms to the script I worked on.I currently don’t have the time to check why the original script failed to work correctly (even if I did, I’m, right now, on antiX 22, that does not use Pipewire 🙁 )
My suggested script has gone through some changes, since I proposed it.NOTE and extra suggestion: the information that appears, when the user hovers the mouse pointer over any option on Control Centre states something like “Instantly disable Pipewire audio server…”
I think that only people that know what that means should click that option… Currently, the corresponding button on Control Centre is interactive, it changes, letting users know if it enables or disables Pipewire.
That did not happen when the Toggle was added to Control Centre. Maybe the script could just instantly perform the change (i.e. enable/disable Pipewire) AND display a notification like warning stating that Pipewire was on or off.
The text displayed in the Control Centre tooltip can be improved a bit, to explain in just a few words, what an audio server is…EDIT: I just realized, testing in an on-line virtual antiX, that the Control Centre tooltip has an “error”: “Instantly Enable… and remove it from system start up”. It should be “add it to the system start up”. If we have to fix that, we may as well try to explain what an “audio server”/”sound server” is…
P.
- This reply was modified 1 year, 10 months ago by PPC.
- You must be logged in to reply to this topic.