How to prevent/disable suspend on idle (PipeWire)?

Good evening everyone!

For some reason I had two sound servers running at the same time, so I installed manjaro-pipewire earlier. This removed a few conflicting packages (manjaro-pulse, pulseaudio-zeroconf, pulseaudio-alsa, pulseaudio and pulseaudio-bluetooth). After rebooting, PipeWire is now running as the only sound server.

The problem now is that my speakers start humming when no sound is played for a short time. I think this probably happens because the device is put into power saving mode when not in use.

Using pulse I could prevent this by commenting out load-module module-suspend-on-idle in /etc/pulse/

How do I do this with PipeWire?

Thanks a lot!

No, you didn’t. Just because PipeWire is installed and the service is waiting does not mean both PulseAudio and PipeWire are actually running at the same time.

You can verify which sound server is running the following command:

pactl info

Revert everything you just did to return to PulseAudio if it works better for you.

And because no one cares apparently about the conflict/issue to go back to Pulseaudio with the help of the manjaro-pulse package, note that to avoid the issue, you need to add another package to install with manjaro-pulse

Hm, inxi said so:

  Device-1: Intel Cannon Lake PCH cAVS vendor: Dell driver: snd_hda_intel
    v: kernel alternate: snd_soc_skl,snd_sof_pci_intel_cnl bus-ID: 00:1f.3
    chip-ID: 8086:a348 class-ID: 0403
  Sound API: ALSA v: k5.15.91-1-MANJARO running: yes
  Sound Server-1: JACK v: 1.9.21 running: no
  Sound Server-2: PulseAudio v: 16.1 running: yes
  Sound Server-3: PipeWire v: 0.3.65 running: yes


It’s incorrect. @h2-1 is the inxi developer. Maybe he knows why. Either way, I suggest creating an upstream issue if there isn’t already an existing one.

FYI, the manjaro-pulse and manjaro-pipewire meta packages are only offered for convenience. They are not a magic wand to switch between audio servers. Manual intervention may be required.

Update: It turns out the reason inxi thinks PipeWire is running while using PulseAudio is because it’s checking for the pipewire service instead of the pipewire-pulse service.


For PipeWire, user can configure/disable device suspend in either wireplumber or pipewire-media-session
PipeWire - Noticeable audio delay or audible pop/crack when starting playback - ArchWiki

inxi said so

inxi is a good tool for showing general system information, but it is not accurate. The inaccuracy does not matter for troubleshooting audio: Users will need more than inxi to diagnose audio issues

inxi has been corrected recently to show ALSA as an API rather than a sound server, but most users didn’t question that there appeared to be 3 sound servers running
and it is showing the kernel version rather than alsa-lib version

I suggest you try installing kernel v6.1 before reconfiguring pipewire session manager
because sometimes a different kernel might not have any audio suspend noise

1 Like

Thanks for the useful information! Added to my personal Manjaro Wiki. Tbh, I just timeshifted back to my previous configuration using pulse since it was working. Thought I had two audio servers running and needed to “fix” that somehow. Thx anyways!

Just a few corrections

  • alsa-lib isn’t a thing, inxi doesn’t check package versions, that’s insanity, with one or two exceptions, but it’s avoided at all costs. If there is no program to query with a -v/–version type thing, which as far as I know there isn’t for alsa, which is an API, of the kernel, in such cases, as with alsa, the version is the same as kernel version since it’s a kernel audio api, basically, like OSS. Those are terms that are accurate enough for my purposes, since they are functionally accurate.
  • It’s also worth noting that it’s quite common for people to complain that inxi is ‘wrong’ about something, but when I do the real research, which they rarely themselves did, I discover that what was wrong was their assumption and belief about what was right, those issues are quite funny when they happen, and they happen fairly routinely, which is one big reason I always verify the claims being made by people stating something is ‘wrong’. Research appears to be a fading skill nowadays, sigh.
  • There was indeed some debate about what to call alsa, and finding conclusive documentation on it was damnedably difficult, but I finally managed to find the explicit statement that it’s a sound api, like opengl is a graphics api, thus, both audio and graphics now show the api in question as an API. This was never really relevant before since pulse and pipewire are relative newcomers compared to inxi. It’s also noteworthy that back in the day, we all called alsa a sound server, that was kind of the standard term for it. But stuff morphs and evolves, and as new sound servers were added, it grew more relevant to distinguish alsa from the new kids on the block, jack, pipewire, pulse. If we go really far back, it was going to be either OSS or ALSA, period, so the question of what to call it never came up, and it wasn’t called either a server or an api, it was just called alsa or oss.
    This change came about from I think a discussion we had on debian forums, where a real audio engineer helped pin down the terminology used, I had initially gone with Interface, which is how ALSA is often described, but he pointed out that in audio, there are roughly 4 types of interfaces, 2 physical ports, 2 in the software stack, so Interface was not a very useful term. The ‘I’ in API is interface, for example. Finally pinned it down to API, but you’d be surprised at how difficult it is to find clear non ambiguous docs about what something actually IS, LOL, it’s way way harder than you’d think.
  • Saying inxi is not accurate isn’t really meaningful, in some areas, it’s much more accurate than anything else, in others, not as much. This is a function of distros and people caring and taking the time to contribute research and energy to improving the accuracy. And of my caring and wanting to spend the huge research time this always involves. This isn’t magic, and I don’t get paid for this, so no real user interest/energy, much less likely I will spend my own on complicated features. If in doubt, see the contributions made actively by your distro, if almost none, that’s where the fault lies, if a lot, then you are part of the solution. It’s not rocket science.
  • inxi isn’t a thing, it’s a very large collection of logical modules and features, some huge, some quite small. Each of those could be considered a thing, and thus you could say, that feature is or isn’t accurate. I don’t know how many such modules there are, I think probably over 100 is my guess, in terms of a bit of data that is distinct to that logic block. Might be much more than 100, several hundred would not surprise me, but I haven’t counted.
  • The only part of inxi that can be considered a single thing might be the core tools it uses to help construct and process the data and print it out, but that doesn’t actually create any data about your system, that is just what inxi internally uses to operate, and what is used to gather the data, but is not the data gathering and processing itself. That could have bugs, but can’t be inaccurate since it doesn’t create any data.
  • If you want to see what user/distro time/energy look like, check out the relatively recent CPU and GPU feature development threads with slackware users on, or if you go back in time, sidux users and the -m/–memory/RAM feature, they were also instrumental in early BSD support. Or, going back a bit again, the Manjaro ARM people, who initially helped get the ARM stuff working pretty well, and put out a fair amount of energy back then.
    Or Stan from, who was hugely helpful in upgrading BSD support in inxi. Or mrmazda, who is largely responsible for the way graphics looks now, along with some RPM distro issues he comes across and which I never see since I don’t use RPM distros, he does a lot of forum support, and is always coming up with new suggestions to make support work better, that’s all behind the scenes, or via IRC. Because they put their energy into it, the stuff got implemented. I only personally care about a subset of the stuff inxi reports on, so for the rest, I rely on people who care themselves, and who are willing to do the tedious research required to figure out what is going on.
  • inxi in a sense is made out of a bunch of these focused energy moments, which then result in reasonably reliable features. The ones that never gained any external energy (like --logical/-L), tend to be weaker since they were mainly developed by me, without heavy user testing and feedback, and thus tend to be less reliable.
  • Note that if I post for debugging / development help and get no real response on a distro forum, I might give it one or two more tries, and if I get no real feedback, I give up on that resource since if they don’t care, why should I?
  • There’s a significant myth also that various tools are ‘accurate’, the main cause of this myth is inexperience, usually, that is, you simply have not seen tool x or y fail or be inaccurate, and simply believe that it’s accurate. inxi is filled to the brim with workarounds and fixes for these errors and glitches in other data sources and tools, which is why personally I tend to trust inxi more than most of the tools out there, but that’s because I know what’s going on under the covers, and I know the immense amount of garbage data inxi has to deal with to derive what is hoped to be an accurate report. This problem is also known as “it works on my system!”.
  • stuff like pipewire-pulse I don’t even hear about, unless I see a thread like this, new stuff comes, and stuff goes, it’s a constant churn, and, again, it’s an easy mistake to make to believe just because something new popped up that that makes inxi somehow wrong or inaccurate, it’s just the churn at work, that’s a constant, no user reports, no user energy put out, and in particular, no issues file on github inxi, then how could all this stuff be known? This is particularly relevant when it’s not even stuff I use or have even heard about. Near as I can tell from package description, pipewire-pulse is pipewire, not pulse. But I don’t follow this stuff that closely, it’s not really that interesting in general.
    Looking, I found that there is also pipewire-alsa, but I don’t really know why either exist or what the point of them is, so I leave it alone,

As with all Free software, users are free to use or not use any bit of it, and with the GPL, it has a nice comment about there being no guarantee of suitability or functionality, not even implied, which is something that people who don’t actually understand what the GPL is or why it worked so well tend to not realize, sometimes even confusing GPL software for corporate run stuff that has large programming teams and large budgets, which some gpl stuff has, and others doesn’t.

I tend to use the simple metric when deciding where and when and how to apply my finite free volunteer energy: are the users of the distro actively contributing time and energy? If not, their concerns are not very high priority to me, though I do strive to make inxi accurate within reason, understanding that some things will just never be possible, some will take a lot of work, and some just aren’t worth it since the results will never really be worth the time, or it’s something I just don’t care about, and have gotten no code/research help with from anyone else, so I leave it alone.

1 Like

Near as I can tell from package description, pipewire-pulse is pipewire, not pulse. But I don’t follow this stuff that closely, it’s not really that interesting in general.
Looking, I found that there is also pipewire-alsa, but I don’t really know why either exist or what the point of them is, so I leave it alone,

pipewire-alsa is an ALSA configuration to set PipeWire as default sound server in ALSA
package replaces pulseaudio-alsa to set PulseAudio as default sound server in ALSA

pipewire-pulse is the PulseAudio replacement sound server

Name                  : pipewire-pulse
Version               : 1:0.3.66-2
Description           : Low-latency audio/video router and processor - PulseAudio replacement

pipewire-pulse is marked as conflicting with pulseaudio
and pulseaudiois marked as conflicting pipewire-pulse
so a package manager will only allow one install

pipewire-pulse and pipewire-alsa are not installed by default on Manjaro, but core package pipewire is installed alongside PulseAudio packages
so when a user checks audio information in inxi -A response is:

  Sound Server-2: PulseAudio v: 16.1 running: yes
  Sound Server-3: PipeWire v: 0.3.65 running: yes

A number of users conclude (mistakenly) that:

I had two sound servers running at the same time

inix said so

(more a misunderstood false-positive than incorrect or inaccurate?!)

If inxi checked pipewire-pulse.service instead of pipewire.service, PulseAudio users would only see PulseAudio (pulseaudio.service) running

Users changing to PipeWire would only see PipeWire (pipewire-pulse.service) running, no different to previous information from pipewire.service

1 Like

I checked into this a bit, and the actual pipewire site explained what pipewire-pulse is pretty clearly. Basically according to them, and this makes sense, pipewire-pulse IS pipewire, but with an additional daemon pipewire-pulse running on top of it, in essence, the sound server is pipewire, nothing has changed, and it will be running if you are running pipewire-pulse, or pipewire-alsa, so inxi is completely correct to note that pipewire is running, and it detects it because it is running, the running test is based on live query to the system after determining that the tool is installed, the second test is to query if it is an active service.

So this isn’t actually either pipewire is running OR pipewire-pulse is running, it’s pipewire-pulse running on the pipewire sound server. Note that pipewire themselves explicitly call pipewire a sound server, and pipewire-pulse a daemon that runs on that sound server.

So the technically correct output is not to make inxi say something that is not true, that is, that pipewire is not running, but rather, to do something like the recent graphics server did:

Display: x11 server: 1.20.2 with: xwayland

That was done to help clarify that it doesn’t have to be xorg or xwayland, you can have xwayland installed without it being operational, or you can have wayland compositor and xorg running, again, with xwayland.

This would be quite similar, it would be a sub-query so to speak, if pipewire is running, then test for and generate a second level of data for pipewire, pipewire-pulse / pipewire-alsa, which are both members of the set of pipewire things running, but they are children of pipewire, not their own thing, since they can’t run without pipewire.

In terms of quality documentation, pipewire is up there, because this was one of the easiest things to find an non ambiguous real answer from the project themselves:

**pipewire-pulse** starts a PulseAudio-compatible daemon that integrates with
the PipeWire media server. This daemon is a drop-in replacement for the
PulseAudio daemon.

In terms of output, it would look like so:

inxi -Ay1
  Sound API: ALSA
     v: k5.19.0-16.2-liquorix-amd64
     running: yes
  Sound Server-1: Pipewire
     v: 0.3.65
     running: yes
     with: pipewire-pulse
        v: 0.2.4
        running: yes

I can’t speak to some fine points, because I’d have to install those packages and don’t want to, would have to test on a vm in terms of seeing what actually can happen and what can’t.

In Debian’s package, again, the language is crystal clear, which is delightful, you’d be amazed how often I spend weeks trying to get a clear declaration of what something IS, lol, sigh.

Replaces: pipewire-bin (<< 0.3.27-2)
Depends: pipewire (= 0.3.65-3), init-system-helpers (>= 1.52)
Recommends: wireplumber | pipewire-media-session-pulseaudio
Suggests: libspa-0.2-bluetooth, pulseaudio-utils
Breaks: pipewire-bin (<< 0.3.27-2)
Description-en: PipeWire PulseAudio daemon
 PipeWire is a server and user space API to deal with multimedia
 pipelines. This includes:
  - Making available sources of video (such as from a capture devices or
    application provided streams) and multiplexing this with clients.
  - Accessing sources of video for consumption.
  - Generating graphs for audio and video processing.
 This package contains the PulseAudio replacement daemon.

It’s a rabbit hole I’d never really thought much about.

1 Like

In latest pinxi, I’ve added this with: pipewire-pulse/with: pipewire-alsa as sub types of the PipeWire audio server line.

    v: k5.19.0-16.2-liquorix-amd64
    running: yes
  Sound Server-1: PipeWire
    v: 0.3.65
    running: yes
    with: pipewire-pulse
      running: yes

This is in pinxi 3.3.25-4


New users on Manjaro forum are often misinformed about 2 audio servers running on Manjaro, based on information from inxi only
Users can also be further misinformed by only being told to install PipeWire to replace PulseAudio
(IMO no Manjaro user should be taking this choice away from another user)

Users are not explicitly advised about how to continue using PulseAudio because there is nothing to do
except disregard information from inxi suggesting PipeWire is also running

alsa-lib is not a thing on Debian Wiki because the ALSA userspace library is renamed libasound2
except for PipeWire offering a drop-in replacement for alsa-lib

pipewire-alsa is a single ALSA configuration file to set PipeWire as the default ALSA output
Package replaces pulseaudio-alsa, but either can be replaced with 2 lines of configuration in ~/.asoundrc
pipewire-jack should be considered for inxi but not pipewire-alsa or pulseaudio-alsa

The only source of information about PipeWire is lead developer Wym Taymans. If he didn’t write all the documentation he would at least have approved it. You should ask him about PipeWire packages and media servers

Like I said, rabbit holes, impossible to know on a per distro basis, which is why I always ignore package data, and only support actual files and programs and process names etc. alsa-lib is just a package name, and thus, from inxi’s perspective, is not a thing, as I said.

libraries are in general also not “a thing” for inxi, because they usually are just files somewhere, and usually not in $PATH, and usually don’t have --version info.

Good info on the pipewire-alsa, I’ll update pinxi for that, and add pipewire-jack.

Note however, pipewire in all cases is the sound server, as the pipewire doc clearly stated, these are just daemons running on it. I thought the docs were clear and well written, and did their job re explaining the stuff, except for the pipewire-alsa, which was not clearly explained. There was a small weak spot because I was not aware of such pipewire daemons as pulse and jack, the detection to see if pipewire is running just looked for pipewire in the running string, that has been corrected to look for pipewire[d] ending with space or eol.

One small note/comment however: when you say “You should ask him about PipeWire packages” what you actually meant to type was “I should do this to help out since research and communication is immensely time consuming [at least 90+% of inxi dev time, maybe closer to 95-98%] and not expect the inxi dev to do everything himself, particularly when it comes to stuff he doesn’t care about or use himself, and besides, I might learn something interesting I didn’t know before”.

Basically the area of software running on system was actually something that I was warned about trying to support in inxi, because it’s such a huge rabbit hole, which will always churn, but as long as it makes sense, and can be clearly explained, I tend to do it, though support/help for those things, particularly with desktop/window manager/compositor/graphics api stuff has been limited basically to one person other than me who is interested in such things, at least, some of them, but only a narrow slice of the possible set (xorg + trinity/kde).

Do note however, if I hadn’t randomly checked this thread, I would still today have no idea that pipewire-pulse/jack are things that exist as daemons of pipewire, I don’t spend all my waking hours tracking down changes and developments in the software stack of free desktops/servers, I tend to focus such efforts on specific goals and development cycles, which tend to cover huge areas rapidly, but those are intensive efforts which are not something I can do all the time, unless someone wants to pay me to do that. In other words, I can’t do it all the time.

Recent such things, as noted above, were the massive CPU refactor, which locked down cpu support for the coming years because it’s so robust and dynamic, and dumps almost all the hardcoded fixes and methods, except for legacy hardware/os/kernels, with one exception, the manually updated cpu matching tables which is where the advanced cpu data comes from, like arch:, gen:, year:, and so on. Happily modern cpu development has slowed to a crawl with increasingly near impossible process node shrinking, so these updates aren’t required as much as in the old days. But the CPU stuff is over 99% research, with no authoritative sources for the data, just a collection of sites that are useful, but none complete.

The other area is the newer gpu advanced data, also manually updated from master lists from some resources online, but in the end, manual to some degree. This is about 95% research re time, give or take.

All these manual matching table items now are split out as standalone tools in pinxi/tools which made maintaining them a whole lot easier long term, so those aren’t as much of a pain as they were last year.

These things all happen when/if I feel like doing them, the cpu stuff I sometimes get some help with but not usually, nobody is interested in volunteering long term research commitment so I end up doing it. One day this will stop being interesting and I’ll stop doing it, but for now, it’s so scripted and automated that the research isn’t that time consuming, and only has to be done every release or two. Same for disk vendors, another huge regex matching table, and some other items.

But software stack stuff, that is just something that has to be added if stuff is added. In this case, I leveraged the existing output syntax used, as noted, for with: xwayland, except that the pipewire daemons, being essentially sub parts of pipewire, have the same version number as pipewire shows, so there was no point in repeating that.

This is now in pinxi 3.25.-6, with pipewire-pulse/pipewire-jack pipewire daemon detections now in place.

This logic also permits the other sound servers to supply such sub daemon data.

Since I’m looking at this now, I may add a few basic tools as maybe -Aa like with -Ia/-ra a report of detected tools, which might be of some utility, though again, the requirement to create another list of detected tools like packages has, but those things don’t change much over time, and the -A feature has always been somewhat barren.

Stuff like pavucontrol, pulsemixer, alsamixer, and so on. That’s pretty easy to do, and would make an actual reason for a new inxi release.

Technically, at least debian packages lists pipewire-alsa and pipewire-jack as plugins, not daemons, only pipewire-pulse is listed as a daemon. As I said a rabbit hole.

Cutting to the chase… pinxi is not in the Manjaro repos; therefore no one is using it. I appreciate you taking the time to address the issue; however writing a wall of text novella here about it doesn’t address the core issue.

The point is, there has been much confusion with inxi reporting both sound servers running when it is not at all the case. says

It provides a low-latency, graph-based processing engine on top of audio and video devices […]

i.e. pipewire may function as an sound server, but by no means does it have to. I can run pipewire just fine with such a configuration that it won’t touch any audio devices. E.g. when one uses pipewire for wayland screen sharing but pulseaudio for audio; this is a supported use case.

Always listing pipewire under “sound servers” when the pipewire process is running can be misleading; see the above example. There is currently no robust way to tell if pipewire is managing audio devices or not (see PipeWire detection (#1835) · Issues · PipeWire / pipewire · GitLab).

One could use something like

pw-cli ls | grep 'media.class = "Audio' >/dev/null && echo "pipewire does audio" || echo "pipewire does not do audio"

but this is not robust by any means(!), nevertheless I think it’s still better than always listing pipewire as a sound server when it is running.

pinxi is the development version of inxi, it’s next inxi. So when I say this fix is in pinxi, it means that people who are aware of this can update pinxi and test it to confirm the fixes, this is the standard way inxi updates happen.

Again, I would urge people here who find issues or believe inxi can be improved, and who can suggest concrete improvements, tests, etc, to NOT depend on my randomly seeing a thread, file an issue on github, do the research, do the testing, propose solutions, I don’t track every distro forum in the world, and when the issue has only been raised here, even if correct, it’s obviously not something particularly urgent or pressing in a larger sense.

For those who can read, however, I noted the difficultly of doing software stack stuff, and also that it depends on people who care about that specific issue taking the time to actually do the research and testing to propose solutions that are useful in the context of inxi.

For example, it is in fact ONLY after posting a lot of text that someone actually noted both the real issue and the possible improvement, but getting people to do this work is like pulling teeth nowadays sadly.

I’m not super fond of having to do super customized tests to detect if something is running or not however, but the method above with pw-cli if valid and more robust than the simple process running test currently used.

This test will alter certain things however, for example, if the test is negative, then pipewire will not show as a sound server unless -Axx or greater verbosity is used since -A by default does not show non running sound servers, and thus, things like pipewire-pulse/pipewire-jack [the latter of which does not appear to be a daemon, but rather similar to pipewire-alsa].

software is a rabbit hole always almost by definition, so it really comes down to: if you care about a bit here or there, do the research, post issues on github, present solutions, and it can probably be resolved. But don’t depend on random comments on your distro forums, I don’t see 99% of them, and only stop by if I saw it, and it seemed possibly interesting or a source for improvement.

I’ll add some of these things to the inxi debugger data collector as well, unfortunately this is all new info for me, so I can’t see what other systems are doing over time with these commands, and experience has shown that ‘works on my system’ generally is not a complete solution. We’ll see.

Audio hasn’t really been revisited much over past years, sometimes it’s worth checking into the stuff again to handle changes and new situations, this sounds like one of those cases.

1 Like

First draft of revised logic, running in pinxi 3.3.25-7 now. Yes, you can install a script and run it, without a package manager!

cd /usr/local/bin && sudo wget -O pinxi && sudo chmod +x pinxi

then use -U to update to newest after that, as with inxi, it’s install once, run forever. This will require more info and testing, currently it appears that the most reliable test is probably pactl info for a positive yes, and for pipewire, as a fallback, it uses the pw-ctl test, which will require more data to confirm it’s a good test for yes running. Currently it says no if that test failed and pactl test also was negative, but that’s probably going to need some tweaks.

This features an initial set of installed tool tests, I used arch wiki for the server tools lists, probably not complete.

I believe if jackd is present that by definition means jack is active as a server, since it’s daemon, aka, server process, is running, so I left that test. Pulseaudio now tests first if process is running, then if running on pipewire or straight pulseaudio, and will note if not running but on pipewire, this may or may not show, depends. Pipewire is probably going to be least reliable and will require more tweaks because I don’t have huge faith in the pw-cli ls method. If pipewire or pulse are detected as active as a process after these tests are all negative, it will show: running: yes (process) because I don’t trust the tests to be right. Pipewire uses first pactl info test to see if pulse is running on pipewire, if so, it says running: yes, and if the above pw-cli test shows yes, then it also shows running: yes.

pinxi -Aaz --vs
pinxi 3.3.25-07 (2023-03-21)
  Device-1: C-Media CMI8788 [Oxygen HD Audio] vendor: ASUSTeK Virtuoso 100
    driver: snd_virtuoso v: kernel bus-ID: 05:04.0 chip-ID: 13f6:8788
    class-ID: 0401
  Device-2: AMD Cedar HDMI Audio [Radeon HD 5400/6300/7300 Series]
    vendor: XFX Pine driver: snd_hda_intel v: kernel pcie: gen: 1
    speed: 2.5 GT/s lanes: 16 link-max: gen: 2 speed: 5 GT/s bus-ID: 0a:00.1
    chip-ID: 1002:aa68 class-ID: 0403
  Device-3: AMD Family 17h HD Audio vendor: Gigabyte driver: snd_hda_intel
    v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16 bus-ID: 0c:00.3
    chip-ID: 1022:1457 class-ID: 0403
  Sound API: ALSA v: k5.19.0-16.2-liquorix-amd64 running: yes
    tools: alsamixer,alsamixergui,amixer,aplay,arecord
  Sound Server-1: PulseAudio v: 16.1 running: yes tools: pactl,pavucontrol
  Sound Server-2: PipeWire v: 0.3.65 running: no tools: pw-cli

For those who don’t like reading, contributing to inxi is probably not for you, since inxi dev is all about reading, sorry.

This issue does seem valid which is why I’m following up on it here, but in general, I’m probably going to be steadily dropping the time I spend tracking distro forums, it’s not effective use of my time, so in future, if you find issues that seem valid, do th research, collect as much info as possible, try to figure out solutions, then post the issue where it belongs, on GitHub - smxi/inxi: inxi is a full featured CLI system information tool. It is available in most Linux distribution repositories, and does its best to support the BSDs. - Note that anyone who at least tries to do research and find solutions will in general get a very good response.

Here’s a test vm of the new logic:

  Device-1: Intel 82801AA AC97 Audio vendor: Dell driver: snd_intel8x0
    v: kernel bus-ID: 00:05.0 chip-ID: 8086:2415 class-ID: 0401
  Sound API: ALSA v: k6.1.8-4-liquorix-amd64 running: yes tools: N/A
  Sound Server-1: JACK v: 1.9.21 running: no tools: jack_control
  Sound Server-2: PipeWire v: 0.3.65 running: yes with: pipewire-pulse
    running: yes tools: pw-cli,wpctl,wireplumber