Open harudagondi opened 2 years ago
These components should probably have its own thread, as the sample rate (the number of audio samples per second) is usually around 44100 Hz, so systems dealing with audio components should be able to run for at least 44100 times a second to avoid underruns.
I believe samples are pretty much always batched, so you don't need to run 44100 times for a 44100 Hz sample rate. As for running in their own thread, rodio (which bevy currently uses for audio) already spawns a background thread for audio handling AFAIK.
samples are pretty much always batched
background thread for audio handling
Whoops, i forgot about that. Maybe AudioListener
and AudioEmitter
could just use mspc channels, as long as it is fast enough.
I have a small demo showing rodio limited spatial audio capabilities: https://vleue.itch.io/rodio-spatial-audio. It's waiting on a rodio release to be upstreamed in Bevy
This issue seems to be resolved, should it be closed?
It currently only does attenuation based on the distance to left/right "ears", it's very far from spatial...
What problem does this solve or what need does it fill?
What solution would you like?
Create two
Component
s:AudioEmitter
: Emits sound from the current position of the entity.AudioListener
: Listens for sounds fromAudioEmitter
. Has its own (potentially same) position.AudioEmitter
's API should be similar tobevy_audio::Audio
, whileAudioListener
works similar toAudioOutput
internally, or computes the resulting sound wave and send it to the mixer.These components should probably have its own thread, as the sample rate (the number of audio samples per second) is usually around 44100 Hz, so systems dealing with audio components should be able to run for at least 44100 times a second to avoid underruns.
What alternative(s) have you considered?
Additional context
See the discussion in the bevy discord in the #audio-dev channel for more info.