1. 50
  1.  

  2. 3

    Note that pipewire works on the BSDs, too. Well, at least, FreeBSD and HardenedBSD. :)

    1. 2

      SPA looks suspiciously similar to COM to me; the whole IUnknown dance…

      1. 6

        It’s been close to 20 years since I last used DirectShow, but my memory from it (and from subsequently using a load of open source media frameworks) was that there are far worse examples to take inspiration from. The entire filter model on top of COM was very clean. The only thing that I didn’t like was that the interfaces often involved passing quite complex structures between objects in the filter graph, which made it difficult if you wanted to move a particular filter out of the process. The GUI tooling on top was fantastic: you could draw filter graphs in a visual editor and then replicate the same thing in code once you’d got the structure right (I think it could even serialise the graph for you in something you could load from your code, but that didn’t work if you wanted to prototype the rough shape but dynamically discover some parts in your program).

        I also vaguely remember something problematic about how it identified the correct decoder for a particular stream type, which made it possible to have a fast and a correct MPEG-4 decoder and automatically select the one that couldn’t actually play the content. That’s probably a fairly easy thing to fix with a new architecture but hard to retrofit in an existing one.

        1. 1

          To the uninformed, what are you referring to?

          1. 2

            All COM interfaces implement IUnknown. IUnknown implements QueryInterface, which basically casts interfaces and lets you get the vtable for an interface if said object implements it. This looks kinda similar; you may know nothing about a class, and need to interrogate it through casting for if it can implement the appropriate interface.

            1. 4

              I mean, this is just a standard way to handle sum types within the confines of C’s type system, there’s not interface implementation or anything going on here. If you look at e.g. json-c, there’s a very similar pattern of interrogating the type of opaque data, and acting on it accordingly.

        2. 1

          I wonder how much of the adoption of this is driven by people hating the author of PulseAudio … and whether the same will happen for systemd or Flatpak at a certain point in time.

          Of course, I don’t want to skip the obligatory: Why the hell isn’t this written in Rust or another safe language?

          1. 4

            Possibly a little bit. But it objectively is a better project and achieved more exciting features than PA in the same time PA managed to become the default and alienate people with bad release quality. Even the PulseEffects project decided to just drop PA support in the next major version.

            To displace systemd or Flatpak someone would have to start a project which does things overall better than them and delivers better quality… and that’s much harder. Both are solid, useful projects solving problems which alternatives don’t.

            1. 3

              PulseEffects

              Audio effects for PipeWire applications.

              I had to snort when I read that. ;-)