https://bugs.winehq.org/show_bug.cgi?id=48230
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- Okay, now I understand part of the confusion. There aren't "3 audio backends" in that specific sense. GStreamer is used as a library to decode compressed audio and video and to handle large parts of the DirectShow streaming API (as well as some parts of mfplat, and in the future probably more). It's not used as an audio backend in itself (e.g. we don't use autoaudiosink). All audio that's decoded by GStreamer ultimately goes through one of Wine's actual audio backends, which are ALSA, PulseAudio, and OSS.
Previously, we implemented decoders for some specific formats in tree. For the reasons given this is no longer the case, and we now handle those via GStreamer. GStreamer is a hard requirement for any application that uses those parts of DirectShow (which is most applications that use DirectShow), which is not quite the same thing as being a hard requirement for Wine (since plenty of applications don't use DirectShow at all).
Similarly, if you don't use 64-bit applications which use DirectShow (and you probably don't), you don't need 64-bit GStreamer. If your distribution's package build scripts state otherwise, that's probably something that should be addressed there. (For example, the Debian packages distributed by WineHQ don't require GStreamer to be installed, though they are built with GStreamer support.)
Yes, I know it's annoying to have to install 32-bit libraries just for Wine. Blame it on the application; we don't really have a choice in the matter. (Besides to emulate a 32-bit system through machine code translation, but that's rather unfeasible.) Yes, I know that from the user's perspective we could simply not use any external libraries, but from a developer's perspective the maintenance cost is a nightmare.