Why couldn't (or shouldn't) buffers clean themselves?

[McSinyx]

Hi,

I'm writing a wrapper for alure in Cython for convenience purposes, and I'm wondering which would be the better way to clean up buffers' cache:

1. Let buffers clean themselves. I notice that the API only expose Context::removeBuffer but any other means for buffer to do this. I can just let the context be an attribute of the wrapped buffer, but I want to know if that introduce any risk, i.e. why the C++ API chose not to do it.
2. Let the context track every created buffer. ContextImpl seems to already have mBuffers, is it safe to just call cleanup on all of them upon context destruction? I don't think this is a good idea though since used buffers will hold the cache for no reason.

Have a Merry Christmas or other holiday of your choice.

[kcat]

The reason buffers aren't cleaned up automatically with context destruction is because there's no guarantee the context is current, which it would need to be to delete the AL buffers. In fact, I think the context can't be current for it to be destroyed. So for Alure to do that, it would need to transparently manage the current context itself, changing it based on what object the caller is using or deleting. This can get complicated when there's multiple contexts and multiple threads being used simultaneously.

More generally, it's also a good idea for an app to properly manage and clean up its buffers when no longer needed, rather than relying on context destruction to clean them up. Given a game or other long-running app, you don't want to be creating/caching buffers as needed but never deleting them until device shutdown. That can easily waste a lot of memory.

[McSinyx]

Thanks for the prompt and detailed explanation. I still have some questions though:

[the context] would need to be [current] to delete the AL buffers

I have not seen that mentioned elsewhere. Does this rule apply to other objects like Source? Or more generally, what's the role of having multiple contexts in one device?

[kcat]

Does this rule apply to other objects like Source?

Yes, just like OpenAL itself. With OpenAL, the current context determines which context and device things like sources and buffers belong to. Alure's objects are essentially wrappers around OpenAL objects, so to delete or otherwise modify a Buffer or Source from Alure, the proper Context from Alure needs to be current for the OpenAL context to be current.

Or more generally, what's the role of having multiple contexts in one device?

One use-case could be to share a device with two independent mixes. For instance if you have the main game sound on the main context, but also want to play something else on the same device without worrying about changes to the main context interfering. Another use-case could be something like split-screen, where you're listening from two separate perspectives at once.

[McSinyx]

Thank you, I think I get it now.