inxi / pinxi Audio upgrades, sound servers, apis, etc, testers?

[Member h2]

Helpful

Up

1

::

To give an idea of the work involved in these things, here’s the inxi-audio.txt doc I made during this process as I realized how much information I was collecting just to get a basic start on the issue. While updating it I found more resources, which let me add to pinxi another JACK audio helper too, which actually was released in stable form very recently, new-session-manager and it’s daemon nsmd.

https://github.com/smxi/inxi/raw/inxi-perl/docs/inxi-audio.txt

Note this is just for the new stuff, the rest is the same logic that Graphics, Network, Bluetooth Devices reports use so that’s not really specific to audio.

These doc files vary massively in quality, since they take a lot of time to make clean and organized, so it’s only in this type of case where I just made it all at once from research I just did that there’s any hope of it being usable and readable, but this one I figured might as well make it nice since it’s all so fresh in my head.

This isn’t all the research required, but it is a fair snippet of it.

Most of the changes you’ll see in Audio sound system report are with JACK, PipeWire, Pulseaudio, and more important, helper tools like pipewire-alsa, pipewire-jack, pipewire-pulse, etc.

inxi system information script (install info) :: inxi git

[Moderator Brian Masinick]

Helpful

Up

0

::

Thank you for the information h2.

I’ve been experimenting with 3.3.26 and the pinxi updates this week. As far as I am able to determine, everything on my HP-14 laptop is accurate.

--
Brian Masinick

[Member h2]

Helpful

Up

0

::

This feature appears to be working as intended, some of the arch derived distros are shipping with the configuration that caused the original issue, false or wrong reports of server presence and/or status, and incomplete info re server/api helpers running, and are now giving complete reports.

The new ‘tools’ report for -Aa also helps show if the user has not installed any of the util/tools packages, which is actually a good indication that they aren’t actually using the server at all as a user. For example if ALSA …. tools: N/A that suggests ALSA is not being consciously used by the person directly, since you can’t really use alsa without alsamixer.

While I did unfortunately find one newish JACK helper, which is core, and done by the project, new-session-manager daemon (forked from the non-session-mamager daemon, whose dev suffered a sadly typical foss blowup and exit), and its associated gui control tool, so far that’s been the only real thing I found that I missed in 3.3.26, but I found that only when reviewing the inxi-perl/docs-audio.txt file, and checking some of the links I’d added, where that helper/too combo was listed on their news page. Still not packaged by Debian though, which is why I’d missed it, though it’s not particularly new, think it first shipped in 2021. JACK however is something used mainly by serious audio people, studio stuff, etc, it’s not aimed at consumers at all, done by the Ardour DAW author among other serious audio recording types.

I’ve also found some issues with xfce, by good coincidence, again, from checking something re the audio, in Void Linux current release, which ships with a valid and correct possible setup, no xprop installed initially, which then broke the existing xfce detection. This was particularly pressing because xfce 4.20 is expected to ship with reasonably full wayland support, which means that except for xwayland, no x tools can be expected to exist there.

I’ve checked the desktop/wm detections, and now there are I think only Xorg specific wm/desktops that depend on xprop, except enlightenment wayland, which I have not tested yet, the version number there depends on xprop -root data.

To me xfce going to wayland support largely means that for that adult run project, they finally consider it worth the time, plus they are being smart and not rolling YADWC (Yet Another Damned Wayland Compositor), but are using the well run wl-roots project, based in sway wm, but rapidly becoming the defacto non gnome/kde/enlightenment compositor standard.

• This reply was modified 1 month ago by h2.
• This reply was modified 1 month ago by h2.
• This reply was modified 1 month ago by h2.

inxi system information script (install info) :: inxi git

[Moderator Brian Masinick]

Helpful

Up

0

::

Thank you for the latest update h2.
I happened to be switching over to Endeavour OS for the purposes of updating my packages there, so I made sure to update my copy of pinxi.
Seems to be working fine. I really don’t need to manage a lot of stuff here, but should I need it, the tool seems to be fine.

pinxi -b
System:
  Host: eos-hp-14fq1025 Kernel: 6.2.8-arch1-1 arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.27.3 Distro: EndeavourOS
Machine:
  Type: Laptop System: HP product: HP Laptop 14-fq1xxx v: N/A
    serial: <superuser required>
  Mobo: HP model: 887C v: 59.11 serial: <superuser required> UEFI: AMI
    v: F.18 date: 11/26/2021
Battery:
  ID-1: BAT0 charge: 40.6 Wh (99.8%) condition: 40.7/40.7 Wh (100.0%)
CPU:
  Info: 6-core AMD Ryzen 5 5500U with Radeon Graphics [MT MCP] speed (MHz):
    avg: 1586 min/max: 1400/4056
Graphics:
  Device-1: AMD Lucienne driver: amdgpu v: kernel
  Device-2: Chicony HP TrueVision HD Camera type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 21.1.8 driver: X: loaded: amdgpu
    unloaded: modesetting dri: radeonsi gpu: amdgpu resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 23.0.1 renderer: AMD Radeon Graphics (renoir LLVM
    15.0.7 DRM 3.49 6.2.8-arch1-1)
Network:
  Device-1: Realtek driver: rtw89_8852ae
Drives:
  Local Storage: total: 238.47 GiB used: 16.41 GiB (6.9%)
Info:
  Processes: 289 Uptime: 34m Memory: 7.09 GiB used: 3.1 GiB (43.7%)
  Shell: Bash pinxi: 3.3.26-4

--
Brian Masinick

[Moderator Brian Masinick]

Helpful

Up

0

::

pinxi -Axx
Audio:
  Device-1: AMD Renoir Radeon High Definition Audio vendor: Hewlett-Packard
    driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16
    bus-ID: 03:00.1 chip-ID: 1002:1637
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor vendor: Hewlett-Packard
    driver: snd_rn_pci_acp3x v: kernel pcie: speed: 8 GT/s lanes: 16
    bus-ID: 03:00.5 chip-ID: 1022:15e2
  Device-3: AMD Family 17h/19h HD Audio vendor: Hewlett-Packard
    driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16
    bus-ID: 03:00.6 chip-ID: 1022:15e3
  API: ALSA v: k6.2.8-arch1-1 status: kernel-api
  Server-1: PipeWire v: 0.3.67 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin

--
Brian Masinick

[Moderator Brian Masinick]

Helpful

Up

0

::

I just happened to notice that the audio implementation is different on Endeavour OS compared to antiX on the same hardware.
antiX uses apulse and other legacy methods. Endeavour OS uses PipeWire and wireplumber with pw-jack plugin.

--
Brian Masinick

[Member h2]

Helpful

Up

2

::

Yes, PipeWire is starting to replace PulseAudio more and more, that configuration you posted appears to be the default for Manjaro, Endeavor, and I think Garuda, all Arch based.

That’s what tripped the issues, PulseAudio was reported as installed because inxi used a test that is too loose to determine it is present, then that showed as off, which was wrong, it wasn’t even installed.

That’s why the pipewire-pulse daemon for example is important, that shows that pipewire is installed as a full replacement for pulseaudio, and it’s running and active. And there are two incompatible pipewire session managers, wireplumber [recommended newer] and pipewire-media-session, so it’s also useful to see if they are present, and active, and which is active/present. If both somehow were active, that would probably be why the user was having a sound issue.

So far the new syntax, which matches roughly the field name syntax used in -G and -ra re API, tools: etc, isn’t bugging me, and the change to status: is not annoying me too much either, the ‘running’ term was too limiting, and in the end, I ended up dumping status: for helpers that are not daemons, and called that type: since they are present or not, and can be modules or plugins, depending.

But most important is I actually documented this while I was doing it, and have updated the docs, so those are some of the better docs in inxi now since they were done all at once, and are not just a bunch of random stuff tossed into a doc file.

The code also is clean because I used the newer perl methods I have been moving towards, which lead to more consistent code and testing of values etc, inxi itself is too big to change it all to use that cleaner style, but the new stuff tries to use it.

• This reply was modified 1 month ago by h2.
• This reply was modified 1 month ago by h2.
• This reply was modified 1 month ago by h2.

inxi system information script (install info) :: inxi git

[Author]

Posts