Announcement

Collapse
No announcement yet.

Wine Developers Plot Their Path For Integrating FAudio As The XAudio2 Reimplementation

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wine Developers Plot Their Path For Integrating FAudio As The XAudio2 Reimplementation

    Phoronix: Wine Developers Plot Their Path For Integrating FAudio As The XAudio2 Reimplementation

    A few days back Linux game porter/developer Ethan Lee joined CodeWeavers to work on Wine/Proton for Valve. In particular, he's going to be focusing on his FAudio project as a Windows XAudio(2) re-implementation. CodeWeavers appears to be eager on getting FAudio merged into upstream Wine...

    http://www.phoronix.com/scan.php?pag...io-Merge-Plans

  • #2
    This is extremely interesting for a few reasons. 1) FAudio is written in C++, and has a different coding style than wine's code, just like DXVK. 2) They are not using submodules, and want FNA development to be part of the wine tree. This challenges the age-old C89 only rule in wine. 3) Wine already has an xaudio solution, and wine currently doesn't have multiple solutions for a single dll in its tree. This means that it will either completely remove the old OpenAL based one, or it will allow them to coexist. My question is, if Faudio and the old implementation can coexist, why can't DXVK and wined3d coexist in the wine tree?

    Comment


    • #3
      > The preferred route they are taking is to occasionally pull in the latest FAudio Git code into the Wine tree and from there make use of it as opposed to relying upon Git sub-modules, shifting FAudio's main development location to being Wine, or other possibilities.

      What is wrong with git sub-modules? There is also something similar to that which I think might have been a better option but I don't have experience with it personally, git-tree or git-subtree, something like that?

      Comment


      • #4
        This article is wrong. It's only Andrew who proposed merging it into Wine, everyone else (and higher-ups in terms of Wine's development) including Henri and Alexandre, do not want to integrate it into Wine, but want to use it like any other standalone library. In other words, yet another dependency, as if Wine didn't have enough.

        That's a real shame because there's yet another fucking dependency that users have to install or compile themselves (if they want the latest and with their own optimization flags). This is the primary reason that integration is far better than relying on external libraries, even if it means duplicated effort: user convenience.

        It's even worse due to the fact that FAudio has dependencies on its own like SDL2.

        But of course, who cares about users?

        Comment


        • #5
          being a dependency isn't going to hurt proton so much, most people using lutris+wine+dxvk understand the need to install extra's on top to get things working.

          Comment


          • #6
            Originally posted by theriddick View Post
            being a dependency isn't going to hurt proton so much, most people using lutris+wine+dxvk understand the need to install extra's on top to get things working.
            Technically, that's the whole point of Proton.

            So yeah, it's good for Proton, worse for Wine than it could be.

            Comment

            Working...
            X