5 ms·

An answer to most of these might be to fix and extend ALSA rather than wallpapering over it and treating it like abandonware.

PaulDavisThe1st 5y ago
ALSA was written to allow psuedo-devices to be implemented in user-space, which is how PulseAudio (and now Pipewire) does what it does. Nobody is abandoning ALSA, it continues to be both the device driver layer and the lowest layer of the audio stack in user-space. [ EDIT: you could make an argument that after many years of experience, it's time to put the lessons learned from JACK and PulseAudio into ALSA itself, and have ALSA provide the sorts of audio capabilities that the two of them, combined, enabled. I don't have much of a position on this compared with the Pipewire approach, which is to do the same thing, but outside of ALSA. There are good arguments for both, but Pipewire is what we have, and it remains as dependent on ALSA as JACK and PulseAudio and just about all other Linux audio has been since 2000 ]
craftkiller 5y ago
which is funny because that's exactly how ALSA was started: https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_happy#c_mqvroo https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...
- md8z 5y ago
  That comment is somewhat problematic and I went into detail about it last week: https://news.ycombinator.com/item?id=28856907 https://news.ycombinator.com/item?id=28856907
  - PaulDavisThe1st 5y ago
    Great comment. Sorry that I missed this at the time.
- PaulDavisThe1st 5y ago
  I've been developing audio & MIDI software for Linux since about 1997. Maybe that makes me a special case, but none of the experience described by the post is familiar to me. I even used to use xmms with ALSA. There's some acorns of truth in that account, but it's been turned into a paragraph of hand-waving half-truth.
- oblio 5y ago
  That's hilarious. And sad. https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html Copy paste the link. Or: > I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short. > It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8? > But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
  - PaulDavisThe1st 5y ago
    The 3rd quoted point.... if applying it the Linux audio stack then ... this is so absolutely fucking disrespectful to people like Takashi Iwai, who has spent 20 years fixing bugs and doing so much "un-fun" work on ALSA. Y'all can vent on Lennart as much as you want, but every time you do you forget the heroes who have worked out of the spotlight, doing the boring grunt work that has kept ALSA working for two decades as audio hardware has changed dramatically.
    - oblio 5y ago
      How would my quote apply to people who do that kind of work? The whole article is about people that <<don't>> do that.
      - md8z 5y ago
        It's pretty rude to insult someone by calling them an "attention deficit teenager" regardless of what they're working on. I would recommend against quoting that article.
        bmn__ 5y ago
        I see you chose to ignore what prompted the rant. Is it deliberate?
codedokode 5y ago
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.

PaulDavisThe1st 5y ago

ALSA was written to allow psuedo-devices to be implemented in user-space, which is how PulseAudio (and now Pipewire) does what it does. Nobody is abandoning ALSA, it continues to be both the device driver layer and the lowest layer of the audio stack in user-space. [ EDIT: you could make an argument that after many years of experience, it's time to put the lessons learned from JACK and PulseAudio into ALSA itself, and have ALSA provide the sorts of audio capabilities that the two of them, combined, enabled. I don't have much of a position on this compared with the Pipewire approach, which is to do the same thing, but outside of ALSA. There are good arguments for both, but Pipewire is what we have, and it remains as dependent on ALSA as JACK and PulseAudio and just about all other Linux audio has been since 2000 ]

craftkiller 5y ago

which is funny because that's exactly how ALSA was started: https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_happy#c_mqvroo https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...

md8z 5y ago
That comment is somewhat problematic and I went into detail about it last week: https://news.ycombinator.com/item?id=28856907 https://news.ycombinator.com/item?id=28856907
- PaulDavisThe1st 5y ago
  Great comment. Sorry that I missed this at the time.
PaulDavisThe1st 5y ago
I've been developing audio & MIDI software for Linux since about 1997. Maybe that makes me a special case, but none of the experience described by the post is familiar to me. I even used to use xmms with ALSA. There's some acorns of truth in that account, but it's been turned into a paragraph of hand-waving half-truth.
oblio 5y ago
That's hilarious. And sad. https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html Copy paste the link. Or: > I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short. > It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8? > But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
- PaulDavisThe1st 5y ago
  The 3rd quoted point.... if applying it the Linux audio stack then ... this is so absolutely fucking disrespectful to people like Takashi Iwai, who has spent 20 years fixing bugs and doing so much "un-fun" work on ALSA. Y'all can vent on Lennart as much as you want, but every time you do you forget the heroes who have worked out of the spotlight, doing the boring grunt work that has kept ALSA working for two decades as audio hardware has changed dramatically.
  - oblio 5y ago
    How would my quote apply to people who do that kind of work? The whole article is about people that <<don't>> do that.
    - md8z 5y ago
      It's pretty rude to insult someone by calling them an "attention deficit teenager" regardless of what they're working on. I would recommend against quoting that article.
      - bmn__ 5y ago
        I see you chose to ignore what prompted the rant. Is it deliberate?

codedokode 5y ago

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.