1. 20
  1. 3

    just like you don’t write audio applications directly to the ALSA API anymore

    Isn’t that a mistake we’ve been paying for for years? Even ALSA itself (vs just fixing/improving OSS as has been done elsewhere) was a mistake in hindsight, but “Oh let’s add a new layer on top instead of fixing the current one” has only ever resulted in years of things being broken.

    1. 5

      I don’t have a magic crystal ball, but I think we could end up in a worse situation if we just bloted alsa/oss with features. Right now we have a nice split where alsa mostly deals with real devices and another layer deals with routing / mixing / dynamic updates. If we ended up with effectively oss+pa in one project, maybe we’d either not recover or have to rewrite everything to fix it. Now we’re pretty much moving from alsa+pa to alsa+pw without the base layer changing much. I don’t think that’s a bad situation to be in.

      1. 1

        But if you don’t need those other features, why not just use the ALSA calls? Even if it goes through the pipewire virtual device or whatever, it seems absurd to constantly rewrite everything when you could just target the base.

        1. 2

          I would prefer to use an API that is high-level and allows me to easily port my application to other environments, rather than use something that is low-level and Linux-specific. In that case the argument is moot; I’m targeting neither alsa nor PA nor PW.