Skip to content

Atomic Audio Functions #892

@bjornbytes

Description

@bjornbytes

It's useful to make some changes to sources and know that they'll all be executed atomically. A common example might be playing a bunch of sources and having them start at the same time, but you also might want to change the volume of a collection of sources, or adjust some effects.

Currently this isn't possible because each individual Source method takes out a lock. It's possible for the audio thread to start playing a source in between any of these calls, so you can't guarantee that the source is in the state you want when it starts playing.

LÖVR could add lovr.audio.play, lovr.audio.pause, and lovr.audio.stop which take a collection of sources, ensuring they are all changed atomically. There are a few issues with it:

  • stop currently has a naming conflict with the existing lovr.audio.stop function, which stops an audio device. The variants could just overlap, but it's probably too confusing.
  • It only lets you adjust playback state, it doesn't let you make other changes to the sources.

There's another idea I've had called like "audio transactions". Basically, all of the audio state would be double buffered. Lua code could modify one copy while the audio thread is using the other copy, and at explicit points the states could be swapped, allowing the audio thread to see new changes.

You could imagine a lovr.audio.commit function that swaps the buffers and lets the audio thread see any changes to sources. boot.lua could call this after lovr.update, so that you don't have to think about flushing changes manually. You could also call this explicitly after making some changes to sources, for slightly better responsiveness.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions