I never had any problem with that, and I am quite sure I did not have to tweak anything. Playing music or listening to a podcast when I am working on games is something I often do, and it does not prevent the game to output its sound.

OK, that's good to hear. Next time I setup Linux I'll experiment w/ ALSA only.

I think what I will do for my program is create an implementation for both ALSA and PipeWire. Seems like that will cover the "high level" and "low level" of the Linux audio stack and other setups like PulseAudio will have to use their ALSA compatibility layer.

aRts?
Now there's a name I'd completely forgotten.
I vaguely recall liking the idea, but also disabling it because of the latency and resulting AV sync issues, and it interfering
with (blocking) my video player of choice. I think that was Xine back then.
Later I think it was Kaffeine with the libxine back-end. GStreamer was another popular thing I avoided, as it usually resulted in audibly lowering the quality of audio sent through its pipeline.
At the time, Linux was not only my main OS. It was my only OS. So everything had to work properly. Including watching DVDs and playing the odd game without excessive audio latency.
Best of luck. ALSA has copious amounts of documentation. Unfortunately, it's mostly autogenerated and pretty useless.

I think I can make it work. Maybe I'll post the code after and you guys can tell me if it works on your pure ALSA systems :)

Some PulseAudio features only work if all of your apps use it. Much like ALSA apps using direct hardware access, if one app bypasses it, you generally won't get proper sound from everything else. And, to be fair, pa does offer some features ALSA doesn't, and probably does a better job of documentation (in spite of its age, ALSA documentation still feels like a jumbled collection of unrelated READMEs written when it was first released; my lack of interest in pa means I never looked at its documentation, though). This need for all apps to use it is why I consider it a replacement for ALSA, rather than just a wrapper.

By comparison, SDL, OpenAL, gstreamer, and many other wrappers are not affected by whether or not other apps use them. If one offers easier API or better portability (e.g. to Windows and/or other UNIX systems, such as OSS), I would encourage you to use them. ALSA does not do high-level audio, so if you want e.g. compressed audio encoding support, you'll want to use a wrapper, anyway. The portability aspect is why I tend to use something like SDL myself, even though I never test on anything but Linux any more.

I had done my backend in PipeWire but in retrospect it seems ALSA would have been a better choice if I wanted to pick one. I agree it's difficult to be the portability of SDL however I get satisfaction from coding things myself where I can. And though I do try and organize things such that platform specific stuff is isolated, I think I'm done with Windows.

I am curious how so many are able to just have ALSA installed though. I installed FireFox on a virtual machine today and was surprised that even that had a dependency on JACK. Are ALSA users primarily using window managers as opposed to desktop environments?

I would consider SDL to still be a low enough level for me to count it as "coding it myself". (With that said, I'd argue that actually generating the sound would count more than simply playing back a media fil.)

On the other hand, when it comes to graphics output, I would say that using an API like OpenGL would count as "coding it myself"; I think I'm finding it more fun making a game in OpenGL than I did making that same game (basically) in Godot. (Yes, I know there are lower level APIs like Vulkan, but writing Vulkan is like writing assembly language (whereas OpenGL is more like C).)

All three are installed on mine + JACK2. JACK2 or JACk in general is the one thing that can mess up an installation I find.

Example: If I wanted just a Pipewire install, I would have to use JACK and not JACK2 I find.

When you have all three and they work together though, sound problems become a distant thought.

Edit: If I had to pick one today, I would still probably go with Pulse with ALSA... Due to compatibility. Friend is using Pipewire like you are using and doesn't seem to have any problems.

I think what you should do in the case you wish to use pipewire is install pipewire+wireplumber.
Then to support other clients using other APIs you can add pipewire-pulse, pipewire-jack, pipewire-alsa. You would not install the "real" versions of pulseaudio or jack.

Sure. Everyone has their own lines they draw where they wish to code things themselves or would rather take someone else's solution. Input, Sound, and window creation are areas I happen to not mind tackling myself. But there was a time I would not have wanted to.

I am tempted to use OpenGL when I get to graphics because it is generally simpler and far less verbose that Vulkan. But I can't help feel my time might be better spent dealing with Vulkan because OpenGL is kind of legacy at this point. Kind of like X, it doesn't feel the best time to be investing too heavily in it.

Thing is:
* OpenGL is easier to learn.
* Learning OpenGL will make it easier to learn Vulkan.

Again, the comparison to assembly language makes some sense here.
* C is easier to learn.
* Learning C will make it easier to learn assembly language.
* (On the other hand, knowing assembly language will help you understand why C code behaves a certain way; the same might be true of Vulkan helping you understand why OpenGL behaves the way it does.)

Haven't even heard about PipeWire. Think I'm using PulseAudio. Or whatever it is Linux Mint uses. But pretty sure it's Pulse.

It could be. Mint is based on ubuntu and newer versions of ubuntu do come with pipewire installed. The weird thing though is that I don't think they are setup correct to use it because they don't come installed with wireplumber which you would kind of need. So they are ultimately likely running thru pulseaudio. I'm sure they'll get it right eventually :)

If you have a recent enough version, there's nothing to prevent you from just installing wireplumber manually via apt.

Yes & I believe that would cause pipewire to be the handler for all the system's audio. But there's no reason to do it if the existing setup is doing everything needed.