Make `bevy_audio` agnostic

[harudagondi]

What problem does this solve or what need does it fill?

• Currently, there are several audio plugins in the bevy ecosystem, like:
  • bevy_audio, uses rodio internally
  • bevy_kira_audio, uses kira internally
  • bevy_oddio, uses oddio internally
  • There's also bevy_synthizer, developed by Nolan#4103 on the bevy discord
• Making bevy plugins for audio stuff is hard, see here, and PR for bevy_fundsp here: harudagondi/bevy_fundsp#6
• Like how wgpu have many backends abstracted away, I think bevy_audio should do the same.

What solution would you like?

• Majority of the types in bevy_audio should be converted into traits

  • Audio will be a trait that supports playing audio with the given settings
  • AudioSource will be a trait that holds static data, and have a new or init static method
  • AudioSink is a trait that has basic methods for playing or pausing audio (plus some other niceties like in bevyengine/bevy#5828)
  • AudioPlugin should hold its own backend, like what I did in bevy_fundsp

• A default backend for rodio, implemented in bevy_audio, or a separate bevy_rodio crate

• Bevy audio plugins that are just backends implement the traits in bevy_audio and should just work

I don't really know what the exact implementation would look like, but I do know it probably would have a bunch of trait magic and generics, sooo

What alternative(s) have you considered?

• Do not do this. Just let third party audio plugins replace bevy_audio outright.
  • As mentioned before, this will make the creation of third party audio plugins that isn't replacing bevy_audio very boilerplatey and kinda hard, as you'll have to make your code work on every audio plugin, and each plugin is very different.
• Do not remove the original types, but create several traits as mentioned above, and make rodio the default in bevy_audio
  • using third party audio plugins will have both rodio, and kira for example, compiled in the same crate, which is not ideal, especially if rodio will not be used in the first place

Additional context

• I'm working on harudagondi/bevy_fundsp#6
• Making your own Backend trait to support different plugins is kinda frustrating
• UPDATE (2022/11/12): I have written a pre-RFC for this, and I'm currently prototyping a new library.

[SolarLiner]

I personally am against this. In a way, kira/rodio/knyst/etc., are all abstraction crates that aim at providing a unified interface for audio processing (with games in mind for most of them). However, almost all of them attempt to be "batteries included" by each providing a different set of effects and features.

There's two layers of abstraction at play here.
The first one is lower-level, and the responsibilty is to provide a framework for taking sources (files, audio input, procedural sound, etc.), processing them through effects, and outputing the result through sinks (device outputs, a file, a mock output, etc.). It should be general enough to support per-source effects, per-group (or per-track, depending on the vocabulary) effects, and per-sink effects (or master effects).
The second one provides useful DSP algorithms to perform certain tasks (providing spatial audio, simulating room reverb, attenuation and propagation delays, etc.), and can theoretically be inserted in any effect slot of any lower-level abstraction as described above.

The reason why there are so many crates, and why they are all providing both levels of abstractions, is because there are a lot of decisions to be taken at every level, leading to different compromises and different designs. There's also a lot of innovation due to Rust being a relatively young language and so there are multiple proposals for how audio programming could look in Rust.

To me, the goal of bevy_audio is to be general enough to be able to use crates that provide the latter level of abstraction (ie. knyst, oddio, fundsp, even kira in some aspects with its MockBackend), but not the former, because designing such a system would be much more complex for little gain, as these crates have been designed as a holistic solution, and therefore don't try to play nice with others.

If you want to run custom audio effects, or sound generation, then bevy_audio should be able to support that, either by having you writing the code directly, or using oddio or fundsp, and have the internals of the routing taken care of for you. This is how other game engines work.

[tychedelia]

https://github.com/bevyengine/bevy/issues/13226 would directly contravene this. Personally, I think audio is annoying and low level enough that it makes sense to just depend on a single implementation, for the same reason that we depend on winit rather than building abstractions over winit.