Open alice-i-cecile opened 9 months ago
I might have a look at this if nobody else has started yet. Based on cpal
's build_input_stream
, it looks like a sensible design would be to create an event for microphone input packets. That way, it can be up to the consumer on how to work with the audio stream, and if a system isn't consuming the events, they'll be naturally dropped.
It looks small enough that I think it can be a part of bevy_audio
, just with a feature flag (e.g., input
). Shouldn't need any new dependencies either, since rodio
re-exports cpal
already.
hey, don't know if this conversation is still open for input, but i've been working on an audio crate recently for bevy that would use a design similar to godot. there will be multiple buses, and one master bus. each bus can have any number of effects, which are stored on the bus in EffectState
s which takes a Box<dyn Effect>
as a field, similar to the render graph nodes. anyways, using this design, we could also make it possible to create asset importers for audio effects such as CLAP or VST, and this could allow those effects to be used by the audio system. the buses will be stored inside of a resource, and then i'm thinking that a very simple component could be created that indicates that an entity plays audio, and what bus it plays it to. then other components can be added alongside that one such as components for audio clip. finally, i would like to make it so that the outputs of buses can be read, to allow for things such as audio visualizers and for microphone input, which would be implemented by allowing each bus to optionally choose to start recording the microphone, which will stream all mic input to that bus.
hey, don't know if this conversation is still open for input, but i've been working on an audio crate recently for bevy that would use a design similar to godot. there will be multiple buses, and one master bus. each bus can have any number of effects, which are stored on the bus in
EffectState
s which takes aBox<dyn Effect>
as a field, similar to the render graph nodes. anyways, using this design, we could also make it possible to create asset importers for audio effects such as CLAP or VST, and this could allow those effects to be used by the audio system. the buses will be stored inside of a resource, and then i'm thinking that a very simple component could be created that indicates that an entity plays audio, and what bus it plays it to. then other components can be added alongside that one such as components for audio clip. finally, i would like to make it so that the outputs of buses can be read, to allow for things such as audio visualizers and for microphone input, which would be implemented by allowing each bus to optionally choose to start recording the microphone, which will stream all mic input to that bus.
did you end up publishing this somewhere? looking to read some microphone input in bevy.
https://github.com/bevyengine/bevy/issues/13226 would be useful for this. kira
doesn't currently support input afaikt.
What problem does this solve or what need does it fill?
Microphone inputs can be useful in various game contexts, either as a gameplay element or as the foundation of voice chat.
What solution would you like?
Add first-party Bevy support, within bevy_audio but behind a feature flag or in a separate crate.
What alternative(s) have you considered?
Implement this by plumbing together an existing crate on your own. While possible, this is nice to handle with a Bevy-specific integration, to ensure that we have high-quality cross-platform support and a simple ECS-native abstraction layer.