Add support for streaming DSP graphs

[harudagondi]

Currently, DSP graphs are stored in DspSources, where it has a definite length. Due to how bevy_audio and bevy_kira_audio works, this means that there is no way on how to play sounds forever, given a FunDSP graph.

Solution

• Add support for StreamingDspSource.
• To be solved in Big refactor for 0.2 #6

Blocked by:

• bevy_audio: Add support for real time audio streaming bevyengine/bevy#5422
  • This could be solved by using
    • bevy::utils::SyncCell: [Merged by Bors] - Remove Sync bound from Local bevyengine/bevy#5483
    • std::sync::Exclusive Tracking Issue for Exclusive rust-lang/rust#98407
    • Solved by [Merged by Bors] - Remove Sync requirement in Decodable::Decoder bevyengine/bevy#5819
• bevy_kira_audio Support playing sounds that implement kira's SoundData NiklasEi/bevy_kira_audio#63
• Soon to be solved with bevy_oddio.

[leeola]

Would this issue be required for graphs with dynamic levels? Eg making a graph which has dynamic intensity via Midi velocity?

[harudagondi]

I believe the answer is yes. By the way, this issue is mostly solved except for integration with bevy_kira_audio, as per issue linked.

[leeola]

Solved how? I wasn't clear on how this could work with Bevy directly, and given the tracking issue is still open on Bevy's side i figured it wasn't possible. For now i'm experimenting with using an external audio thread to manage the DSP.

Is there a better way?

[harudagondi]

I made an example that stimulates a piano. Maybe check this out?

• Add piano example. #32

[leeola]

Yea i think that would work. At first i wasn't sure, but now that i'm wrapping my head around externally threaded solutions, in theory as long as you can access the Shared<f64> pointers then it should work. Even for velocity.

Is there a benefit in this model over the externally threaded examples in your mind? Would the performance be better in Bevy for any reason?

[harudagondi]

The benefit is that you are not going to eat up any threads in the thread pool that bevy uses. It is better to let bevy handle the threads. Otherwise you are taking away one thread that bevy could use for parallelization.