SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
That looks about as good as I can get it, maybe for future, expanding the detections for the server emulators, though I got a lot of them handled, the main issue here was pipewire-pulse running to replace pulseaudio, and a few other helper features, which I'm in particular pleased to find work on Slackware, I also tested in Slax slackware 15.0 and it all seems good there too, though the perfectionist in me would like to get all possible emulation types handled, but it's a good start for now, way better than what was there.
I also learned a fascinating tidbit, which I did not know, that OSS was itself derived from an ancient Linux sound driver, I had always assumed OSS was born in BSDs, but such was not the case apparently, which leaves Linux audio born in Linux, migrated to BSD, became OSS, then migrated back as OSS to Linux, then became ALSA to replace OSS, and Linux sound/media servers continue to evolve. I also learned that you can run PipeWire on FreeBSD, which I also did not know. At least you could in the past.
I still don't actually know what OSS on linux is, is it a server, an API, an interface? I gave up, and just called it an API for Linux, but given almost nobody runs Linux OSS, it's not a big deal, but it was something I could not find a good answer for. Some call it a framework, which to me is just a term people use when they don't know what something is.
Thanks everyone here for taking a look and posting results, as usual, exposed some unexpected corner case things which are also nice to get handled, like the unwrapping long list of alternate drivers.
The main goal here was to as quickly as possible get a reasonably accurate fixed audio server/api report released into current inxi, so I'm glad a fair number of issues were exposed, also glad I was reminded here to check the older os version, which exposed more glitches, mostly all fixed now as well. I even found a bug in the debugger, which didn't manifest in newer os, but would hang in older, 4.9 kernel based in this case, bluetoothctl was getting passed an invalid option '-- list' (note the space) which modern just ignores so I never noticed it when running the debugger, but it hung that version totally. Having bugs in the debugger is an obvious problem for debugging, lol, sigh.
And yes, huge oversights continue, for example, unable to get OSS version in 2.4 kernel, from 2005-sh era Linux, lol, but even the modern OSS version method is a total hack which may only work on Debian, I don't know, but bit by bit... Fun fact: early ALSA had an actual version number reported by /proc/asound/version, then at some point, they switched to just showing the current kernel version as version number. I found that when figuring out when version was failing for older ALSA (syntax of line slightly changed and inxi didn't use robust enough parsing).
But not bad, at least it's not embarrassingly wrong now, albeit possibly incomplete for some systems re the helpers and core tools reported, but that's easy to upgrade if there is demand / data for that. Demand can be determined if you feel a strong sense of outrage that inxi is failing to report what you view as a core or key helper or tool.
When I compare, I can deduce that the PipeWire process is running, but it's active state cannot be determined, but in your case, the process is not running at all. Without sudo/root, mine would show an 'off' for pipewire [it's actual user state], and a simple 'active' for PulseAudio if run as user, not sudo/root.
So inxi is giving a lot more to go on now than before, and it's not trying to make up answers to things it can't know when run as root/sudo. I didn't actually realize that Jack/Pulse/Pipewire are running as user processes in many cases, which can be stopped or started without the process itself going away, that took some testing, then to discover that as a user process, root/sudo had no access to their real states. These are all new features. Plus of course the RoarAudio/NAS (Network Audio System) server support added, the former of which I'd never heard, only found it by going through all the Debian sound related packages and looking for helpers and servers I didn't know about, same with NAS. There's probably one or two more obscure sound servers I missed.
So far I'm liking the outputs, seems like things are working as hoped. There's probably some more corner case audio server things that won't work quite right, but this is a nice start. And it's not going to be blatantly wrong anymore, like reporting pulseaudio is present but off because it found pactl in PATH, luckily I found that glitch when I was doing my test vm, I installed some package that had pactl but not pulseaudio itself, and it worked fine, but then inxi said pulseaudio was there when it wasn't, then I realized, oh, head slap, that test was bad all along, not conclusive but acting as if it were. The OSS present test was also bad since various oss emulator tools would make it appear as there as well, but that's less of an issue, but it was a similar failure.
Many issues like that have been resolved, hopefully I didn't create too many new ones with the fixes.
I am glad to see that the main methods are working for Slackware without any changes required, I think there might be helper plugin or module detections that might not work, but the main ones so far are all showing up nicely.
Still looking solid, assuming what it is reporting is correct, of course.
Looking at that however does make me wonder if maybe I should have used two terms for 'off', or modified the 'off' to indicate if the process is simply not there, or of it's there, but the actual server is turned off, which is a valid condition for at least jack and pipewire, not pulse I think, though not certain about pulse. Like 'off', 'stopped', for example. But that's not a good idea since when it's off it's stopped. These terms are tricky. Maybe something will come to me in the future, most pressing was to get wrong reports corrected, the future can bring any fine tunings that might make sense.
kjhambrick, that's a case I could not figure out if it can happen, your examples shows it can, that is, no ALSA detected.
Can you give me a brief how-to of what you did to not have ALSA running or visible? Did you compile the kernel with no ALSA? This was one of the areas I was not filled with certainty about.
ALSA is a test that, like OSS on BSDs, relies on the presence of a file (/proc/asound/version for ALSA, /dev/sndstat for OSS, but only if no /proc/asound/version, in which case it's ALSA using OSS emulation, unless it's the new linux OSS, which has the program ossinfo, which BSD OSS does not have from what I can see). I could not find out if ALSA itself as a kernel API can be disabled, but still be present, and I had no way to test if that state can happen or had happened, since then ALSA should report as present but disabled. The same issue goes for BSD OSS).
With the new logic, in general you will get more reliable audio sound system data as user, not root with inxi now. But the root reports allow for basic deductions/assumptions to be made that are quite likely to be right.
I was wondering if systemctl aka the systemd Slackware users are free of might have something to do with the user/root detection difficultly, since current pulse/pw set the sound server to run using the systemctl --user switch, which enables it per user, not for the system, but also, jack_control start/stop does the same, switches it on for user process. I believe however that slackware for pulse and pipewire would switch those servers on systemwide, is that correct?
I can see some room for future improvements, and I'm trying to document stuff in inxi-perl/docs/inxi-audio.txt reasonably well so I don't have to try to guess at why things are the way they are, but that also is not complete or comprehensive, but the base for future fine-tunings is laid reasonably well now.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
