Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak with MuseSounds/MuseSampler #23112

Open
DmitryArefiev opened this issue Jun 6, 2024 · 1 comment
Open

Memory leak with MuseSounds/MuseSampler #23112

DmitryArefiev opened this issue Jun 6, 2024 · 1 comment
Assignees
Labels
needs info More information is required before action can be taken P1 Priority: High regression Regression on a prior release

Comments

@DmitryArefiev
Copy link
Contributor

DmitryArefiev commented Jun 6, 2024

Steps to reproduce

  1. Open Task Manager (and watch MuseScore)
  2. Open big score with MuseSounds (MS4SOUNDS_Beethoven__Symphony_No._9__Op._125.zip)
  3. Playback, stop playback/start playback, start playback from beginning etc.
  4. Observe RAM amount (it's growing)
  5. Close score - RAM is not released as it should
  6. Open score again - it takes more RAM than before

Screenshots/Screen recordings

bandicam.2024-06-06.15-29-35-181.mp4

MuseScore Version

4.4

MuseSampler 0.6.3 (latest version from MuseHub)

Regression

Doesn't occur in 4.2.1 (with the same musesampler version)

Operating system

Windows10

Additional context

No response

@DmitryArefiev DmitryArefiev added regression Regression on a prior release P1 Priority: High labels Jun 6, 2024
@metasekk
Copy link

metasekk commented Jun 7, 2024

FYI, the second part of this issue, whereby closing and reopening a score doesn't free up memory when using MuseSounds, has had its own report here: #22721

A point that could be worth mentioning about the second part of the issue (that is, #22721): I can reproduce it in 4.2.1 (as well as in olders versions actually), whatever MuseSampler version I'm using. However, the rate of growth of memory is much lower than in 4.4 or 4.3, which can give the impression that it doesn't happen (and in that, it is similar to the scores using MS Basic instead of MuseSounds, that do also exhibit memory increase at lower rates).

RomanPudashkin added a commit to RomanPudashkin/MuseScore that referenced this issue Jun 10, 2024
Because it locks the pointer, EventAudioSource loses ownership of it and can no longer destroy it
RomanPudashkin added a commit to RomanPudashkin/MuseScore that referenced this issue Jun 10, 2024
Because it locks the pointer, EventAudioSource loses ownership of it and can no longer destroy it
RomanPudashkin added a commit to RomanPudashkin/MuseScore that referenced this issue Jun 10, 2024
Because it locks the pointer, EventAudioSource loses ownership of it and can no longer destroy it
@DmitryArefiev DmitryArefiev reopened this Jun 26, 2024
@RomanPudashkin RomanPudashkin added the needs info More information is required before action can be taken label Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs info More information is required before action can be taken P1 Priority: High regression Regression on a prior release
Projects
Status: Issues to fix
Development

No branches or pull requests

3 participants