https://bugs.winehq.org/show_bug.cgi?id=50779
--- Comment #27 from Zeb Figura z.figura12@gmail.com --- (In reply to Rafał Mużyło from comment #26)
Created attachment 73210 [details] log in wine 7.18
Hmm, you know, part of the problem might just be on the box. Cause I might be barking up the wrong tree, but glib's "-Wl,-z,nodelete" might play some role here.
Thanks. I don't think nodelete matters, because that'll only add more VM usage once, rather than every time.
Rather, it looks like the application is just creating a new filter graph every time it plays a given sound, and then never destroying it. It does stop the filter graph after the sound is done, though. This is consistent with 90107bba making things worse; previously we would essentially clean up all the GStreamer resources by also resetting the GStreamer filter to the null state. It's also consistent with 3b885fb5f making things worse, since that's another thread we create for every filter graph.
Testing shows that Windows doesn't even leak the filter graph's message thread (rather, it seems to be shared among all filter graphs). So while it's possible that we're doing something wrong (missing graph events?) and that the game is supposed to be cleaning up its filter graphs, my guess is that we really do need to avoid creating any extra threads. That will be annoying.