3 ms·

ALSA is already overcomplicated. What I expect from ALSA is being able to enumerate audio devices and being able to send audio to hardware without any transform

ALSA is already overcomplicated. What I expect from ALSA is being able to enumerate audio devices and being able to send audio to hardware without any transformations. The rest is the work for the userspace daemon.

ahefner 5y ago
I guess? If I have a video player or a game/emulator in the foreground then I think it deserves direct access to the audio device and I just don't like the idea of a userspace sound server in the middle. For a music player or whatever other random stuff, sure, mix it however, send it over Bluetooth, who cares. I've given up fighting PulseAudio, though, and with one audio device I can't have it both ways.
- PaulDavisThe1st 5y ago
  PulseAudio obeys a (dbus) protocol that Lennart and I worked out that allows JACK (or Ardour) to show up and say "hey, I want the device". Any other application could implement it. Pipewire has (AFAIK) implemented the same protocol.
  - ahefner 5y ago
    That is super cool, thanks for the information!
PaulDavisThe1st 5y ago
That's what ALSA does. You don't have to use any other features of it. However, the task is a bit more than you're describing, because in 2021, users expect things like: * hot-pluggable devices (so you need a device notification protocol) * ability to lock the device to prevent settings modifications (very important to pro-audio/music creation settings). macOS calls this "hog mode". Also, you're eliding the distinction between the capabilities of an API and where it gets implemented. Contemporary audio has all sorts of requirements that could be/should be/are implemented in user space, but it's unclear if they should be a part of the ALSA API or some layer(s) above that.