View Issue Details

IDProjectCategoryView StatusLast Update
0030555DocumentationManual ContentPublic2019-05-15 14:44
ReporterStewart BishopAssigned ToMark Alexander 
PriorityLowSeverityC - GeneralReproducibility100%
Status ClosedResolutionFixed 
Product Version2.2.1 
Target VersionFixed in Version2.2.3 
Summary0030555: Manual Content: audio_destroy_stream() should mention that we only free memory for the sound file, not the streaming pool
DescriptionWithin the sample project, 5000 audio streams are created and then destroyed, the game starts at roughly 8mb and once all the streams are created and destroyed ends up double the amount of memory.
Steps To Reproduce1) Run the game in the debugger
2) Press space to create the streams and sounds
3) Press enter to destroy the streams and sounds
4) See that the memory hasn't been completely freed
TagsNo tags attached.

Activities

Russell Kay

2019-02-22 14:01

Manager   ~0063292

Last edited: 2019-02-22 17:26

View 2 revisions

This is not a bug as all that is being allocated is the streaming buffers the actual stream has been deleted (we do not reclaim the streaming buffers)

perhaps a bit more explanation here - in this particular example (which is quite contrived) it is forcing the engine to commit all the resources to opening 5000 streams at once and prepare for playing all of them, this commits all the possible Ogg decode threads (currently limited to 4) and all the audio buffers and all the audio sources, these have overhead that are freed but the memory is kept in a pool for reuse so the memory is not freed again - you can see this by reallocating those 5000 streams after a time period (as it will take several frames for the threads to start and stop and for processing overhead of the streams to be reclaimed) so waiting for a second or 2 in an alarm then reallocating them you can see that memory does not go up again.

In general if you are looking for memory leaks then be aware that we do pool resources in the engine for reuse (if you have used them once you will generally want to use something like it again, might be a different stream or sound resource) and we avoid the memory allocation overhead through these pools - but the memory may not appear to be free from the debugger (it has just been committed to a particular system from which it will be reused)

Dan

2019-02-22 17:31

Adminstrator   ~0063301

Will add this to audio_destroy_stream() so we can clarify this for all users. Moved this report to the Documentation project.

Mark Alexander

2019-03-08 12:23

Developer   ~0063457

Fixed