teawrecks

Hah, pipewire, sorry.

I was describing my setup from memory, here's what I actually have:

play "`find <path-to-clips> -type f -name "*.wav" | rofi -dmenu -i -fuzzy`"

I then have this bound to a key combo in my qtile config which will pop up a menu so I can fuzzy search for a clip to play. However, this alone will just play the clip. To get it to go through discord, I also have a file ~/.config/pipewire/pipewire.conf.d/50-null-sinks.conf with this in it:

context.objects = [
    {   
	factory = adapter
        args = {
            factory.name     = support.null-audio-sink
            node.name        = "mic-loopback"
            node.description = "Mic Loopback"
            media.class      = Audio/Sink
            audio.position   = [ FL FR ]
            adapter.auto-port-config = {
                mode = dsp
                monitor = true
                position = preserve
            }
        }
    },
    {   
	factory = adapter
        args = {
            factory.name     = support.null-audio-sink
            node.name        = "input-mix"
            node.description = "Input Mix"
            media.class      = Audio/Sink
            audio.position   = [ FL FR ]
            adapter.auto-port-config = {
                mode = dsp
                monitor = true
                position = preserve
            }
        }
    }
]

This creates two new nodes that I can use to combine audio into a single source. I then use a combination of the pavucontrol and qpwgraph GUIs to control what audio streams go where. I wire my actual microphone along with the output ports of "Mic Loopback" to the input ports of "Input Mix". Then whatever app I want to play back through my mic, I wire up to the input ports of "Mic Loopback". To wire SoX up to Mic Loopback, I play a clip that's long enough for me to make the switch, and then it tends to remember that for the next time SoX launches. Finally, I wire Input Mix up to discord or whatever program I'm using.

The rofi/play combo is rock solid, I really like that. The pipewire/qpwgraph/pavucontrol part could probably be improved. It can feel a little non-deterministic, but really I think I don't fully understand what each app involved is doing to manipulate the pipewire graph, or how to configure them so they don't try to override each other when a pw node is added/removed.

Edit: quick note. You might be wondering, what's the point of having both Mic Loopback and Input Mix? Couldn't I just have applications go directly to Input Mix? Yes, but generally you want to also hear the sound yourself, without hearing your own mic, and you want to be able to pick a single output device from within the app (most apps don't let you choose more than one). Having two separate nodes lets you split off the output of Mic Loopback to both Input Mix and the output associated with your headphones/speakers, that way you don't hear yourself too.

I do exactly this using rofi to select a clip, pipe it to play (part of SoX), have a qpwGraph profile route the output to a null pw node (along with my mic input), then route that to discord or whatever.

I have to think that nvidia isn't dumb enough to look around at their competitor's linux support, and look at the reliance on linux for compute in datacenters, and look at their pile of fancy new AI chips that they're going to try to sell to data centers, and think to themselves, "ahh, I know the best move, poach the best nvidia linux dev in the world so that ~2% of gamers are forced to use our proprietary driver!"

My guess is they're doing this to make money on AI, they couldn't care less about linux gaming. If we get an open source driver out of the deal, I won't complain, but I bet the consumer GPU driver has little to do with why they hired him.

Why is that? Does the motherboard effectively just not have enough inputs for all the disks, so that's why you need dedicated hardware that handles some kind of raid configuration, and in the end the motherboard just sees it all as one drive? I never really understood what SCSI was for. How do the drives connect, SATA/PATA/something else?

Yeah, I've had a cifs share in my fstab before, mounting it to a folder in my home, and I took the PC off-site for a lan party, and just trying to ls my home dir took forever for some reason. Commenting it out and restarting fixed it all.

Good luck with the new install!

Any chance you have a network share that it might be trying/failing to mount?

Sounds like you need to install polkit for the window manager you're using (xfce-polkit or lxqt-policykit on arch). That should enable apps to request root using the login popup.

Even if you can run your .net code on linux, it's better for you to run on the actual platform you'll be deploying to. You could dual boot just for work (that's what I do) or try running in a VM, but I assume your work is hard enough without generating new friction.

Hah yeah, this was in the back of my mind. I forgot the context of it, though, thanks.

Modern Android Do Not Disturb is configurable enough for you to do this. Allow your family contacts through, block the rest.

Side note: I hate it to my core when people copy code mindlessly

Get ready for the world of AI code assist 😬

Yeah, so it sounds like your complaint is actually with application not propagating relevant error handling information to where it's most convenient for you to read it. Linux is not at fault in your example, because as you said, it returns all the information needed to fix the issue to the one who developed the code, and then they just dropped the ball.

Maybe there's a flag you can set to dump those kinds of errors to a log? But even then, some apps use the fail case as part of normal operation (try to open a file, if we can't, do this other thing). You wouldn't actually want to know about every single failure, just the ones that the application considers fatal.

As long as you're running on a turing complete machine, it's on the app itself to sufficiently document what qualifies as an error and why it happened.