I'll be honest, I don't even remember where I got that snippet. It made the EQ controls appear in greenjeans' app, but I didn't do listening tests. I'm guessing the second block should read type equal, not type plug. Why would someone put a deliberate error in there? Wait... did I get tricked into copying AI slop?!

Whenever you see broken packages, it's a good idea to try apt-get -f install to see if apt can fix the problems for you. It doesn't always work, but it is worth trying. libc6-dev might be important. For example, I need it to install my WiFi drivers. This makes me wonder if you are having connection issues. Are you able to install any packages at all? What error message are you seeing when you enter apt install synaptic?

The API documentation is an absolute nightmare. In fact, the only real "documentation" is the source comments. They get scraped by doxygen and posted to the ALSA site, but most of the links from the index page just go to blank pages. It's been this way for years!

At least there's some online documentation for the C API, I guess. ALSA has an official set of Python bindings which wrap essentially the entire C API. The ALSA devs call it "pyalsa," but if you search for that name, you will find only a completely unrelated, unfinished, decade-old hobbyist project. (in fact, I think there might be two of them!) There is absolutely no online documentation for the real Python ALSA bindings. In fact, the only way to read the documentation is from within Python itself.

Unfortunately, the ALSA bindings also seem pretty buggy. get_volume works, but get_volume_dB always seems to return zero. Maybe I'm using it wrong, but the sparse documentation certainly doesn't give any hints. Attempting to use the mixer callback facility invariably results in the Python interpreter crashing.

I saw some confusing things when I was looking at other people's mixer code. There seemed to be this persistent belief that you had to open the snd_hctl device before opening the snd_mixer interface. I have no idea where they got this idea, but it's completely unnecessary.

Even the ALSA devs don't fully implement their own API. I have a card that shows the "Mic Boost" control twice in alsamixer. The element shows up during both capture and playback enumeration, but it's marked as "common." The application should check for this attribute and only show the control once.

EDIT: After posting the question below, I realized something potentially more important. The value of XDG_RUNTIME_DIR set by shed isn't being exported to the session. As a result, pipewire commands run in terminal windows (such as pactl & wpctl) don't work. If I manually export it as /tmp/1000-runtime-dir from my ~/.xsessionrc then everything works fine. I'm not sure why this happens, since I see in your code that shed explicitly exports the variable. Of course shed can't export the value, I should have realized a script can't export to its invoking script unless it's sourced. However, in this case, even sourcing doesn't work, probably because shed runs in the background and doesn't exit.

I noticed I was accumulating multiple GUISessionXXXX directories on repeated login/logout cycles, since shed was creating a new directory each time from the new PID. It all gets cleaned out on reboot, but the XDG spec says we're supposed to delete these directories between login sessions. Would it make sense for shed to delete the directory on exit if shed created it? I'm not sure whether there might be processes still trying to access this directory after shed exits, but I'm guessing if shed created it, then only shed services are using it.

Has anyone actually been able to get file sharing to work on Windows 10 or later? I gave up a while ago. My searches indicated that Microsoft has completely broken local file sharing in recent versions Windows to push "the cloud." Users asking for help on support.microsoft.com just get a sales pitch for OneDrive.

When I have to boot into Windows, I use Cygwin to mount remote SSHFS shares hosted on the Linux systems. Unfortunately, I can't get it to work in the other direction, even though Cygwin supposedly supports it now.

Huh, that's strange. I installed fail2ban on both a Trixie and an Excalibur system recently and both worked perfectly (once I set the proper logging method.) Maybe it's because I used nftables and pynotify from the start? Those seem to be part of some people's "fixes."

OK, thanks. It didn't occur to me that the logic to handle XDG_RUNTIME_DIR being unset wasn't be in the release version. I will update to master and keep an eye on the log.

(Later edit) It's all working now. I cloned from master, ran make && make install, then confirmed shed was running. It automatically creates a runtime directory at /tmp/1000-runtime-dir/GUISessionXXXX each time the X server starts. I put the three PipeWire service files in ~/.config/shed/services/ as you showed in the other thread, and now they're starting as well. Now I'm thinking about what else it might be good for. I think I'll try creating a service for starting Deskflow. It's not quite as complicated to run as PipeWire (it doesn't need a socket, for example) but it would still be neater to use shed.

Glad I could help. I'm catching up on the thread and looking at the code for EDX-0's shed, and I have to say, he had all the runtime directory stuff figured out a long time ago. I wasn't aware of how much work had already been done on the problem, or how complex it was.

You mention using a chroot: by coincidence I just had a similar problem installing Devuan on a dual-boot system. When I installed grub from inside a chroot, os-prober couldn't find the Windows partition. However, after I rebooted into the new Devuan installation, I ran update-grub again, and this time it found Windows. So you may want to try running update-grub again, just to see if it picks up Windows this time. Be sure to edit /etc/default/grub per kapqa's instructions to enable os-prober.

Yeah, it went right over my head, EDX-0. I had a vague memory of that previous PipeWire thread, but when I searched a few days ago, this thread came up first. I recall my reaction to the previous thread being,"looks complicated, glad I don't need to worry about this!" I respect that you wrote your script to be POSIX compliant. It did occur to me while reading this thread that a "user session manager" would be useful. I guess it's another case of systemd taking all the air out of the room.

I would certainly not recommend that people indiscriminately pile-on services without a good reason. I'm only starting PipeWire because I want to run OBS Studio, which requires PulseAudio. At least I have the option of only turning on PW when I need it. PulseAudio leaves your system in a broken state if you try to disable it without completely purging it.

That's interesting, Maybe you have set one of the other envvars it checks. The error message says PIPEWIRE_RUNTME_DIR or USERPROFILE work as well. I also read somewhere that dbus may help with setting up some of this environment stuff, but it didn't work for me. Can you determine where pipewire is opening the socket on your system? Here's the exact error I get when I start pipewire without XDG_RUNTIME_DIR:

[E][23:49:58.480001] mod.protocol-native | [module-protocol-:  756 init_socket_name()] server 0x562d794d35c0: name pipewire-0 is not an absolute path and no runtime dir found. Set one of PIPEWIRE_RUNTIME_DIR, XDG_RUNTIME_DIR or USERPROFILE in the environment
[E][23:49:58.480143] pw.conf      | [          conf.c:  602 load_module()] 0x562d794b0190: could not load mandatory module "libpipewire-module-protocol-native": No such file or directory
[E][23:49:58.480400] default      | [      pipewire.c:  124 main()] failed to create context: No such file or directory

I unset XDG_RUNTIME_DIR and instead set PIPEWIRE_RUNTIME_DIR. It seemed to work just as well. The latter might be a better option. Since it's specific to PipeWire, it could even be set by the script without interfering with other programs that might use the value of XDG_RUNTIME_DIR.

If anyone else has been looking for the documentation for the .asoundrc format, I found it at the official ALSA wiki. It was kind of buried in a half-broken list of links on the Documentation page. If that link ever goes down, there's also an archive here. It would be nice if .asoundrc actually had a man page, like xorg.conf, and many other system configuration files.