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

[Earwurm] Support audio sprites #34

Open
beefchimi opened this issue Mar 12, 2023 · 1 comment
Open

[Earwurm] Support audio sprites #34

beefchimi opened this issue Mar 12, 2023 · 1 comment
Labels
✨ Feature New addition to the codebase (feature, utility, component, etc.) 🧐 Question Further information is requested

Comments

@beefchimi
Copy link
Owner

beefchimi commented Mar 12, 2023

An "audio sprite" is a way to combine multiple sounds into a single file. This would result in a single larger file... but would also reduce total network requests to 1. Depending on your situation, an audio sprite might be efficient.

In order to support this, a Stack would have to accept a range that it "restricts a sound to".

Something like:

const stack = new Stack(id, path, context, gain, {
  // Clip the `Sound`, starting at `1000ms` and ending at `4000ms`.
  range: [1000, 4000]
});

Not sure yet if we are able to cut up a AudioBuffer to that exact range, or if we would have to carefully check start/end times whenever a Sound is played... this would require investigation.

There are a few different ways I can imagine implementing this:

// Option 1
manager.add(
  {
    id: 'SpritePart1',
    path: 'path/to/sprite.webm',
    range: [0, 1000],
  },
  {
    id: 'SpritePart2',
    path: 'path/to/sprite.webm',
    range: [1000, 2000],
  },
  {
    id: 'SpritePart3',
    path: 'path/to/sprite.webm',
    range: [2000, 3000],
  },
);

// Option 2
manager.add({
  id: 'MySprite',
  path: 'path/to/sprite.webm',
  sprite: {
    key1: [0, 1000],
    key2: [1000, 2000],
    key3: [2000, 3000],
  },
});

I probably prefer Option 2. Either way, we need to iterate over each sprite > range and instantiate a new Stack.

I worry that this pattern won't fit well with the current implementation:

  • Do we continue to let Stack "fetch and decode" upon .prepare()?
    • Are we potentially fetching a much larger file multiple times if .prepare() is called on different "ranges" before a "cache" has been made?
    • Are we also decoding a much larger file every time?
  • Do we need to fetch + decode ahead of time, and pass the "clipped buffer" into new Stack()?
    • We would need to update Stack to accept a buffer instead of a path.
      • Does stack then need to retain that buffer in memory?

Ultimately, my concerns give me pause over implementing this feature. The current design of Earwurm might not be suitable for "audio sprites". I think we would have to make pretty drastic changes:

// Business as usual
const manager = new Earwurm();
manager.add(source1, source2);

// Except that we no longer `get` individual `stacks` anymore.
const firstSound = await manager.prepare(sound1.id);

firstSound.play();
@beefchimi beefchimi added the ✨ Feature New addition to the codebase (feature, utility, component, etc.) label Mar 12, 2023
@beefchimi beefchimi added the 🧐 Question Further information is requested label Jan 15, 2024
@beefchimi
Copy link
Owner Author

Worth discussing whether or not this is really even a feature we wish to support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ Feature New addition to the codebase (feature, utility, component, etc.) 🧐 Question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant