oakmound / oak

A pure Go game engine
Apache License 2.0
1.52k stars 84 forks source link

Refactor Audio Interface to reduce number of OS streams #189

Closed 200sc closed 2 years ago

200sc commented 2 years ago

Currently whenever you want to play an audio element we tell the operating system "here's a new audio to play" and go through a song and dance exchanging data with the OS to open up a stream so we can play the audio.

A theory of design for a better system: What if we only did that procedure once, and handed back to (probably a library, not the user) an open stream that any audio could be played on? If you had multiple concurrent audio streams you wanted to play, you would open up more streams (e.g. one for music, 1-4 for sfx), and audio playing would add itself via a writer interface to be played by that stream.

This would address two problems:

  1. our current audio setup requires the entire audio data is known at start, so we need to read entire files into memory and then write them out
  2. sometimes when an audio ends there is artifacting or clipping because (I think) of an operating system quirk on Windows-- if we never or rarely ended the audio stream this would not happen.