Add a virtual maybe_ensure_capacity(float p_seconds) method to AudioStreamPlayback to support decoding on the main thread

[ellenhp]

Describe the project you are working on

Godot Audio!

Describe the problem or limitation you are having in your project

People keep complaining about Opus not being an option, mostly due to its ability to substantially reduce file sizes.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Opus decoding probably doesn't belong in core, for a variety of reasons really. But it would be really nice to make a GDNative extension adding an AudioStream/AudioStreamPlayback pair and custom resource handling. The main issue is that it's not appropriate to do the decoding on the audio thread for the reasons outlined in godotengine/godot#7496. Adding this maybe_ensure_capacity(float p_seconds) method to be called on the main thread every frame would allow AudioStreamPlayback objects to, if appropriate, decode and buffer frames of audio every frame. During a mix operation the frames can be pulled from the buffer using a memcpy on the audio thread. No allocations or deallocations, no syscalls etc. No skips!

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

This method will be called by either the audio stream player nodes or the audio server depending on the fate of godotengine/godot#51296. Either way, it'll pull the value for p_seconds from a project setting. Tuning that project setting will be tricky but there's really no need for it to be any higher than the maximum frame time expected on the slowest hardware being targeted plus the audio latency (again pulled from the project settings).

The behavior will be implementation defined, but it can be a no-op for all built-in audio types. The overhead will be one vtable lookup + a function call per audio stream playback per frame, which is a small price to pay for letting people add their own audio codecs IMO.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It could theoretically be worked around with an audio stream generator and sufficiently advanced plugin wrangling, but it really wouldn't be the kind of drop-in experience that I think users want.

Is there a reason why this should be core and not an add-on in the asset library?

It's tiny, and its sole purpose is to support an add-on so I think it's an appropriate thing to add into core.

[ellenhp]

I think this can be solved with an autoload singleton and some GDExtension code. Really any way to get a callback from the main loop would be acceptable here, it doesn't need to call into AudioStreamPlayback directly. Closing.