Pipewire and volumeicon startup proposed solution for antiX 23

Forum Forums General Tips and Tricks Pipewire and volumeicon startup proposed solution for antiX 23

  • This topic has 138 replies, 18 voices, and was last updated Jan 31-10:54 pm by Brian Masinick.
Viewing 15 posts - 106 through 120 (of 139 total)
  • Author
  • #119056

      hi abc-nix,

      No problem with your comments. They provided a very useful guide to me. I am happy that the timing issue is clarified and manageable.


      (Not to ignore the useful comments of others in this very nice community.)



        4. If configured, the xdg-autostart commands will be processed first. These can be found as .desktop files in /etc/xdg/autostart. If LOAD_XDG_AUTOSTART is enabled, and pipewire was configured to start from here instead of the startup file, it would start before the startup file, even if LOAD_STARTUP_FILE was disabled and you only used the WM startup file. But enabling this option also means having to navigate the folder and manually disable (with root privileges) each of the ones you don’t want started with the system. You can see the drawbacks.

        First of all I want to thank you for extensive analysis of desktop-session. You pointed me to closer looking at this and subsequent enhancement of pipewire start process.
        I understand that we are off topic by discussing desktop session, as the topic is the issue of appearance of volumeicon for pipewire users, but I want to point to your analysis and understanding of session startup process that was instrumental in your enhancement of pipewire process that led to sound and volumeicon working without fail every time.
        I just want to comment the quoted part with my observations that might introduce a twist in the theory:
        – XDG Startup bundle appears to be invoked regardless of specification of XDG_AUTOSTART in desktop-session.conf. Leaving the default value of ‘false’ it looks like the XDG_AUTOSTART items are starting anyway.
        – I created an appropriate desktop file for Pipewire and added to XDG Autostart, leaving XDG_AUTOSTART value in desktop-conf as default (=false). I also removed (commented out) startup of Pipewire from desktop-session startup, hoping that starting from XDG Autostart will start Pipewire sooner.
        No such effect, however. Pipewire starts from XDG Autostart just fine, but later than desktop-session startup. Apparently XDG Autostart execution is invoked at some point (we know now that the XDG_AUTOSTART=false in desktop-session.conf did not have any effect), but Pipewire came up quicker from a simple ‘pipewire &’ in desktop-session startup, than from XDG Autostart. Apparently whatever starts XDG Autostarts does not wait for that sequence completion and starts desktop-session startup items immediately.
        So my testing showed to me that for Pipewire the start process is quicker if started from desktop-session startup than from XDG Autostart, resulting in volume icon starting vs. not starting, with the same sleep value.
        So, in result of this testing, I am falling back to your previous enhancement you pointed me to, namely by reducing session startup delay value from default 2 sec to 0 I was able to reduce sleep value for volume icon to 1 sec, which makes delay in volume icon insignificaant.
        Thanks again…

        • This reply was modified 6 months, 3 weeks ago by olsztyn.

        Live antiX Boot Options (Previously posted by Xecure):


          Seems some still do not understand, Alsa is essntial to linux sound, pipewire pulse jack runs on top.

          If Alsa is not started earlier in the boot process then pipewire will fail.

          I really hope as abc-nix implied pipewire will become an option in a newer point release.
          The whole issue is causing loss of confidence in antiX, several users who have moved to other distros
          did so after reading in this forum. Trying fixes and wasting hours of work or study time. They are busy
          and inexperienced, asking them to build from base or remove pipewire as far as possible is not a good option.

          Please note, this is not a criticism of abc-nix, his work and really useful and constructive comments
          are highly appreciated. As is the work of all others involved in making antiX the most flexible lightweight
          distro on the planet…

          • This reply was modified 6 months, 3 weeks ago by Xunzi_23.

            @Xunzi_23 – I would greatly appreciate a complete and detailed “how to” remove pipewire from antiX 23 full and restore a pure Alsa sound server… That way I can change the Toggle script to correctly completly disable pipewire (or install it). This will be great no matter is future versions of antiX stick with pipewire by default or no. My praticular vote is: stick with pipewire by default, but have an easy GUI way to use pure alsa if the users so require.

            @abc-nix – A strange report: yesterday, I booted my updated antiX 23 live iso on my netbook and I was surprised when I did not have any volumeicon. I ran Control Centre’s audio test and it produced sound. I ran volumeicon from the terminal and it poped up and managed the volume during the audio test – so I thought, “ok, it’s just a problem with the volumeicon delay, no big deal”. Inserted volumeicon, with a delay, on icewm’s startup file, loged off and back on to live antiX. No volumeicon… hum…. I did what I wanted to do and fired up ungoogled chromium’s appimage and opened youtube (even on the single core atom CPU I was glad that it managed to play 480p videos almost fluidly)… but no sound! I launched pavu and it gave an error that I did not wright down. Sound test just worked fine, but no audio on the browser. Volumeicon refused to open.
            “pkill wire” followed by “pipewire-start & sleep 10 && volumeicon” still did not correctly start pipewire. I powered down the netbook and booted twice. In each of those 2 times, I got pipewire (and volumeicon) working normally. In about 1/10 or 1/20 of the times I boot antiX live from USB pen drives, I get some random error- particularly on that crappy netbook- I hope this pipewire thing was one of those instances.

            @anticapitalista – if antiX Full sticks with pipewire by default, it’s probably better to change xmms’s settings to use pulseaudio (Marcelo noticed that he could not play a video in celulloid and play audio from xmms on antiX 23, because of that default xmms setting).


            • This reply was modified 6 months, 3 weeks ago by PPC.

              I see your point Xunxi23, but

              They are busy and inexperienced, asking them to build from base or remove pipewire as far as possible is not a good option.

              Possibly the same users will complain that there is no sound with bluetooth and firefox .Explain to them how to install and insert pipewire is not such a simple story either.


                “pkill wire” followed by “pipewire-start & sleep 10 && volumeicon”

                Maybe I’m on the wrong track here but could we agree that the way to start pipewire, including in the startup script is pipewire &
                or might
                pidof -q pipewire || pipewire &

                and not pipewire-start &

                I emphasise this here again because I had bad results with pipewire-start & here like duplicate pipewire and wireplumber instances.

                • This reply was modified 6 months, 3 weeks ago by caprea.

                  could we agree that the way to start pipewire, including in the startup script is pipewire &

                  Yes. I agree.

                  I was just trying to debug whatever the temporary problem was, and reverted back to my original notes on how to force stop pipewire and restart it… I’m not recommending that anyone should try to do the same. Every other time that I tried my live antiX 23 Full updated (including abc-nix’s fix) it never failed. Running “pipewire” now correctly starts every program pipewire requires to run on antiX (wireplumber and pipewire-pulse, but I’m saying that by heart). In theory, pipewire-start should do exactly the same, but it’s has timing problems on some devices… Probably I should just have tried “pipewire”, not “pipewire-start”…



                    In theory, pipewire-start should do exactly the same

                    Yes, you are right. The new updated pipewire-start does exactly the same.
                    Strange enough there have been problems on my system when pipewire-start was used in the startup file
                    What is used here now on the upgraded antiX is pipewire & on three systems and three different hardware until now without problems.

                    • This reply was modified 6 months, 3 weeks ago by caprea.
                    Brian Masinick

                      This one (to me) is the best if you are using Pirewire –
                      pidof -q pipewire || pipewire &

                      However, at least for me, all three of the approaches have worked fine, and they’ve given me a more consistent audio experience across various tools that generate audio output – YouTube, Web browser sites with audio (and I’ve checked several different browsers, all work). I haven’t tested every single audio/video combination, and I’m fully aware that many other people have been experiencing a LOT of problems, but I will say at least three of my hardware platforms work really well with this infrastructure, so my use cases seem to be ones that pipewire has addressed.

                      For those who DO have pipewire enabled, I recommend running
                      pidof -q pipewire || pipewire & in whatever startup or configuration chain you are using.

                      For those who just can’t get pipewire working, I think we have other discussions and conversations here that describe how to configure an ALSA only approach; look for these.
                      I also know that @PPC is interested in scripting a tool that will provide mechanisms for trying out both approaches; maybe a collaboration between @PPC and @abc-nix will lead to some useful tools and/or scripts in that space.

                      Brian Masinick


                        Hi Xunzi_23,

                        I certain respect your view of Pipewire and ALSA.

                        As a permanent noobie, I understand that ALSA is the official base for sound, upon which everything else is an add on.

                        My problem has been that I find it difficult to get to work, even for my modest needs. I am sure that is because of my lack of the appropriate knowledge and skill.

                        But, given that lack, Pipewire feels like an easy to use tool to meet my simple needs. And I don’t feel that it is a violation of the basic UNIX mantra, unlike systemd (which I work daily to avoid).

                        If circumstances change, I would have no emotional problem about switching back to struggling with ALSA.



                          One week passed since the latest post on this topic with no new issues reported as related to volume icon. Is this topic considered resolved (instrumental to resolution is the methodology developed by @abc-nix)?
                          From my own experience I can confirm that pipewire, as default sound setup, works for me with no further issues. In result of tuning some settings suggested over recent time by @abc-nix, anti-apXos and others in related threads I was able to reduce the ‘sleep’ before invoking volume icon to 1 sec. and antiX with pipewire proves rock solid in my experience, having all this tuning implemented.

                          Live antiX Boot Options (Previously posted by Xecure):


                            Hi all,

                            Just now, pipewire didn’t start properly on my antiX22–>antiX23 full system. Interestingly, when I looked at VLC, it displayed (what I think is) the default huge list of audio choices that it displayed until Pipewire was tweaked to consistently initiate and work. After rebooting, Pipewire was running and VLC went back to offering “built in analog stereo” as its only audio device choice.


                            Brian Masinick

                              @stevesr0 what is the method you are using to start pipewire?

                              @abc-nix has recommended a few ways but since then a minor change was made, hence my question.

                              On my system

                              are all running; since we’ve had multiple approaches, I forget the most current one, but
                              I *think* it is to run pipewire & and the program starts everything as needed;
                              check this to be sure I’m not forgetting the correct details.

                              The previous method was to check for existing PID for pipewire, if none, start it, — pidof pipewire || pipewire
                              then check for existing PID for pipewire-pulse, if none, start it, pidof pipewire-pulse || pipewire-pulse
                              then check for existing PID for wireplumber, if none, start it, pidof wireplumber || wireplumber — and that should do it.

                              IF what you’re doing doesn’t work, this approach still works.

                              in one place:

                              pidof pipewire || pipewire
                              pidof pipewire-pulse || pipewire-pulse
                              pidof wireplumber || wireplumber

                              Brian Masinick


                                Hi Brian,

                                I am using what I understand to be (one of) the current methods and it is generally working automagically. Today was the only time it didn’t work. I could have done the pkill wire, followed by pipewire which has worked, but I chose to reboot, figuring that if it happened twice, it was worth investigating.

                                If it only happens on rare occasions, I will just live with the slight imperfection, since the “fixes” are so easy.

                                I was just reporting in as a “good citizen”. The VLC thing seems to be related, but again, as long as it works, I am not motivated to spend time analyzing it.


                                Brian Masinick

                                  I’ve had super good results with pipewire. As we know and as we’ve read repeatedly from others, some people like it but others can’t stand it, and when I read something about the Red Hat/IBM project having something to do with the effort, it began to make sense – people are “smelling” something similar to the systemD debacle that has torn factions of the Linux community apart ever since the Debian project started to look for an alternative to the long classic sysVinit method, and instead of choosing another method, the project chose to go with systemD. Had that effort confined itself to ONLY an init related project, MAYBE it would have been better received, but no, it was 1) a lot more than just an init managing daemon, 2) it was sponsored by a big commercial American company that was swallowed up by one of the largest corporations in computing history and 3) it’s a binary image; not sure if the sources are available, but as noted above, while they are able to parallelize the init for multiprocessors, the code is considered tainted and thus there’s a great deal of controversy.

                                  I can only speculate that these matters are among the things that leave a bad taste concerning pipewire, even though the two only have a “potential” of development being performed by individuals who are, or have been, employed by the same group that hoisted the other stuff upon the Linux community. If that IS what the debate is about pipewire, all I can respond is that Linux is about choices and we all have the choice to use pipewire, systemd, one distro, another distro, or choose a proprietary solution.

                                  As much as I understand the init system arguments, I’ve found many distributions, including Debian and multiple Debian derivatives, plus other non-Debian distributions that are “tainted” by the systemd stuff and yet those systems work pretty well too. siduction is the best example I can think of. It’s a VERY good distribution. It’s written by some talented people, a few of them are as volatile, maybe even more so than Torvalds himself has been accused of, but you can’t argue much about the quality of their work; it’s excellent – AND it has that systemd stuff all over it. I just checked and EndeavourOS, another very good distribution, ALSO uses systemd – and probably pipewire too.

                                  I’m definitely not choosing sides, attempting to open wounds or start arguments, but I am suggesting that even tools that not everyone is going to like, love, or prefer may, and probably do have value, even if they hit a nerve when it comes to their approach.

                                  So whether it’s pipewire, systemd, free versus proprietary software, or some other controversy, it’s all software, with various different use cases, advantages, disadvantages, features, and issues.

                                  What I’m REALLY pleased about is that antiX has managed to improve it’s feature set with a very small penalty in the size and features it offers.
                                  By offering a Version 6 kernel (which has now been updated a couple of times to the credit of our developers), we’ve added a significant number of additional systems that can now run our software without a significant effort on the part of individuals in order to run on modern hardware.

                                  Anticapitalista himself may recall during the antiX 21-22 lifecycle that I had some problems getting one of my systems to run antiX. It was because my hardware required the support offered in either a very late version 5 kernel image, or better yet, a Version 6 image. I spent a LOT of my own time finding distributions that would boot on that hardware and finally found TWO that did – MX Linux – but ONLY in the AHS edition (advanced hardware support), and siduction – Debian based systems. I got multiple non-Debian distributions working, but that didn’t make my effort very easy.

                                  So when I compared what was in these versions – newer kernels, newer libraries, and the wireless modules I needed, thanks to multibooting I installed antiX, MX Linux AHS and siduction, then I copied library modules, kernel modules, kernels and missing wireless libraries or firmware into my antiX configuration, and after many iterations, I GOT IT working!

                                  The reason I’m telling this story is that antiX was such a huge improvement I did not have to go through all of this to get the new images working, so I installed both the runit and sysvinit versions without issue on my HP-14, and on my Dell Inspiron 5558, which CAN work with older kernels, I installed those same two versions PLUS I took an OLD antiX image and went through the process of migrating from Bullseye to Bookworm with antiX – and that worked too.

                                  I write this extended essay to state that we can enjoy this great software despite living in different cultures, different political, religious, economic, and social ideas and values, and an interest in a wide variety of different things. We don’t have to agree about much if we are different, but we can enjoy common software, value our differences and respect a variety of viewpoints.

                                  I’m very happy to represent this team as a longtime user, practically since the beginning of this distribution, I’ve tested, written documentation a few times, proof read a lot of stuff, tested as many things as possible, moderated discussions, and raised controversial issues while attempting to maintain a civil attitude at the same time; I hope no matter where we stand on any of these matters we will choose to continue to applaud our distribution, support our developers and testers, and be respectful to one another.

                                  I hope this long note catches you in good health and spirits. I have the unfortunate experience of living in a place where some fantastic people, who have lived long, productive lives, are either ill, have recently passed, and one person who is very dear to me, is in “hospice care”, meaning the number of days he has remaining may be very few. Therefore, I ask each person to cherish those around you, have regard for one another, and find positive things to share, even when we some times disagree about the particulars; in the end it really will not make that much difference; we have a great community and some great software. May the work that is being done provide you with something you can enjoy and share with others.

                                  As a line in a decent movie once stated: “Be well!”

                                  Brian Masinick

                                Viewing 15 posts - 106 through 120 (of 139 total)
                                • You must be logged in to reply to this topic.