Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle processor intensive audio effects? #22

Open
ericrosenbaum opened this issue Feb 3, 2017 · 0 comments
Open

How to handle processor intensive audio effects? #22

ericrosenbaum opened this issue Feb 3, 2017 · 0 comments
Labels
Milestone

Comments

@ericrosenbaum
Copy link
Collaborator

ericrosenbaum commented Feb 3, 2017

Ideally, all the audio effects would be applied at the level of each sprite or clone. In audio terms, each sprite or clone would have its own audio effects chain that includes all of the active audio effects, with its own settings for its own sounds.

Unfortunately, some of the audio effects are processor intensive: echo, reverb, fuzz, and robot. Instantiating them all for each of a potentially large number of sprites or clones would quickly cause audio dropouts or other glitches.

Right now, as a workaround, the AudioEngine creates a single instance of each of these four effects, through which all sounds are played. Any sprite or clone can set, change, or clear them, but the results affect all sounds.

(The pitch effect and pan effect are less processor intensive and so are instantiated by the AudioPlayer for each sprite or clone).

Some questions:

  • Are there ways to re-implement the echo, reverb, fuzz and robot effects to make them less processor intensive?

  • Should we dynamically create and destroy audio effects nodes when they are enabled and disabled by blocks?

  • Should we dynamically create and destroy audio effects when a sprite or clone starts or stops playing sounds?

  • Should we try a hybrid strategy that simulates having individual effects chains for sprites, using a single one? In that case, the single global effect would be set to the value requested by the sprite that most recently played a sound. I think this would require a data structure to track sounds as they start and end. For example, sprite 1 sets the reverb to 10, and starts a sound, causing global reverb to be set to 10; sprite 2 sets reverb to 50 and starts a sound, causing the global reverb to be set to 50; sprite 2's sound finishes but sprite 1's sound is still playing, so the global reverb is set to 10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants