Add `bevy-cpal` crate to `bevy-audio` about bevy HOT 2 CLOSED

I'm not too sure about the usefulness of making this a separate crate -- the only useful stuff to expose directly from cpal is the configuration structs, and it would make sense to expose (or abstract) those in bevy_audio directly. Other use-cases can be handled within Kira's model, or need to use cpal directly anyway (ie. using audio inputs or additional outputs).

The question is, do we abstract cpal away from the user in an ECS-forward way, should we, and in either case, why should we do it in another crate?

To me, the "cpal is the winit of audio" is kind of true, but irrelevant, as using bevy_winit has immediate benefits (ie. event handling, window management, etc.), but a bevy_cpal would give you nothing more than being able to query for avilable configurations. This means to me that this crate would be very light, and not provide any convenience, as audio processing would need to happen off the ECS any way, and so you'd be forced to work directly with cpal directly anyway.

For these reasons I'm going to give my thumbs down on this; audio configuration is something to consider for Bevy Audio v2, but I don't think we should spread ourselves thin over several crates, when this could easily be a (small) extra module on the main audio crate anyway. Besides, I don't think this should be part of the initial scope, as it can easily be added later without breaking changes.

from bevy.

Closing in favor of letting the audio team doing their thing. It sounds like features related to audio input won't be upstreamed in kira for a while though. We'll just do our own thing in Nannou.

from bevy.