Memory leak in iOS -- not destroying audio correctly.

[jjgmckenzie]

Will work on repro over weekend. Have used claude to fix in a forked branch, but truthfully I'm unsure what parts changed specifically are necessary for the fix, only that it has found a fix.

[wsamoht]

How did you find the memory leak or what brought it your attention? Assuming you are calling destroy?

[jjgmckenzie]

Apologies for the lack of reproduction- has been hectic here.

@wsamoht Correct - calling destroy. Use case is an application that plays a lot of different 'primary' audio, streamed; so we destroy the previous audio; then create the next, as there can only be one primary at a time. As the application switches from track to track; the memory usage in iOS continued to increase, despite destroy() being called, where we would expect it to decrease as the tracks are switched and increase as more is streamed.

[wsamoht]

A possible fix in a PR would be helpful. It is interesting that destroy is not doing the job. the audio source gets removed from the list so maybe iOS just isn't running garbage collection on it in a timely manner.