Sample Rate Retention Problem M4.4.X

cfirwin3 commented 1 month ago

Issue type

General playback bug

Description with steps to reproduce

All of the 4.4 variants (including 4.4.2) have a problem with forgetting the sample rate after a while. I am constantly having to go to the audio preferences to reset the sample rate after several minutes. It will suddenly play in a glitch-like fashion, extremely slowly, making an echo effect... I reset the sample rate and then it's fine. Then it does it again.

Supporting files, videos and screenshots

What is the latest version of MuseScore Studio where this issue is present?

4.4.2

Regression

Yes, this used to work in a previous version of MuseScore 4.x

Operating system

Ubuntu Studio 24.04 Pipewire 48000 and/or 44100 sample rate

Additional context

No response

Checklist

[X] This report follows the guidelines for reporting bugs and issues
[X] I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
[X] I have attached all requested files and information to this report
[X] I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

RomanPudashkin commented 1 month ago

@cfirwin3 could you do the following: as soon as the problem occurs, go to Diagnostic -> Save diagnostic files and upload the zip file here. That would help us a lot

cfirwin3 commented 1 month ago

@cfirwin3 could you do the following: as soon as the problem occurs, go to Diagnostic -> Save diagnostic files and upload the zip file here. That would help us a lot

I've got the file. Where do I upload to?

RomanPudashkin commented 1 month ago

Upload it to the comments

cfirwin3 commented 1 month ago

Upload it to the comments

diagnostic.zip

Here it is. Found that GitHub wouldn't accept it without the .zip extension which was hidden on my system.

RomanPudashkin commented 1 month ago

@cfirwin3 could you download this build, reproduce the problem on it, and send me the diagnostic files again? This build has some additional diagnostic information enabled

cfirwin3 commented 1 month ago

@cfirwin3 could you download this build, reproduce the problem on it, and send me the diagnostic files again? This build has some additional diagnostic information enabled

Here you go: Diagnostic.zip

Problem was replicated by playing, editing and then letting it sit for a couple minutes while I sent a quick email. Upon return, the program behaved as if the sample rate was off again (although it indicated the proper rate in the drop down). I also noticed earlier that upon creating a diagnostic report .zip, the program behaved normally without resetting the sample rate. But... resetting the sample rate ALWAYS solves the problem when it goes wrong.

Hopefully that helps!

bkunda commented 1 week ago

This needs to be bumped to a different release project for now as it's proving to be extremely difficult to reproduce.

fernandomartin777 commented 6 days ago

I have exactly the same problem. Even after having an option to adjust sample rate in Linux the sound starts to stutter with usage. Here's how I reproduce it. Under a Linux distro that uses pipewire as default audio system (mine is Ubuntu 24.04), go to preferences, adjust the audio output to default and adjust the sample rate according to what works for your system (mine works in 48000). Create a new score using muse sounds instruments, go on editing it, adding notes, deleting, moving them up and down, playing, stopping etc. After some time the audio starts to stutter and cannot go back to normal unless Musescore is closed and opened again. Since it usually happens after few minutes of usage, it's impossible to write a full score, what renders the software almost useless. PS: In the previous version there was no option to adjust samplerate in MU so I adjust it in pipewire using command line and that same bug described here happened. That means that adjust MU and pipewire to the same samplerate does not work correctly anyway.

fernandomartin777 commented 6 days ago

This needs to be bumped to a different release project for now as it's proving to be extremely difficult to reproduce.

I left a comment describing how to reproduce it. All we need is a linux distro with pipewire natively. It worked in previous MU versions because pipewire was not implemented in several distros. As it is being now, MU 4.x audio is unusable with pipewire.

diedeno commented 5 days ago

I have the same behavior on a system without pipewire (Ubuntu 22.04)

fernandomartin777 commented 5 days ago

I have the same behavior on a system without pipewire (Ubuntu 22.04)

Strange. I never had issues in ubuntu 22.x and 22.x until I upgraded to 24.04 with pipewire. But there are some other strange behaviors. Last night I played a score with muse harp without issues in 4.4.3 beta. But when I start a score using muse strings, brass or woodwinds it's terrible. And I also had issues with the harp in past. 4.4.3 was sluggish to open windows. It seems that 4.x series has some memory or resources management issue in linux.

diedeno commented 5 days ago

I never had the issue before neither. Could it be that the problem started since we can change the buffer size to much lower values? (i'll try using higher buffer size values)

cfirwin3 commented 5 days ago

The problem does not show up on the Jack Transport Pull Request build (and has not on all of the prior base iterations). Currently the Jack PR is based on 4.5, but I don't think that the master 4.5 actually solves the problem.

Perhaps it is a memory issue? I know that it occurs more frequently on my lower powered machines. But as I said, the problem showed up on later 4.x releases and was not around earlier. And again, it does not present on the Jack builds at all. I would assume that it has something to do with the code dealing with buffer size and sample rate, given that resetting the sample rate in real time immediately but temporarily fixes the problem.

cfirwin3 commented 5 days ago

This needs to be bumped to a different release project for now as it's proving to be extremely difficult to reproduce.

I left a comment describing how to reproduce it. All we need is a linux distro with pipewire natively. It worked in previous MU versions because pipewire was not implemented in several distros. As it is being now, MU 4.x audio is unusable with pipewire.

I was using prior M4 builds exclusively on Pipewire. I am also using the Jack PR on Pipewire. This problem (while it MAY be related to Pipewire... it is a new problem that did not exist on prior M4 builds). Be aware that distros like Ubuntu Studio run Pipewire by default at a sample rate of 48000. On previous M4 builds, you would have to set Pipewire to 44100 to allow M4 to work. The symptoms at that time were the same, but they started at the onset and could not be resolved without changing the system sample rate. So the symptoms now, with M4 running at any sample rate (which is the newer feature) produces a response that is identical to a sample rate mismatch... but it does so intermittently rather than consistently.

fernandomartin777 commented 4 days ago

I never had the issue before neither. Could it be that the problem started since we can change the buffer size to much lower values? (i'll try using higher buffer size values)

I tried different buffer sizes and it didn't change anything.

fernandomartin777 commented 4 days ago

The problem does not show up on the Jack Transport Pull Request build (and has not on all of the prior base iterations). Currently the Jack PR is based on 4.5, but I don't think that the master 4.5 actually solves the problem.

Perhaps it is a memory issue? I know that it occurs more frequently on my lower powered machines. But as I said, the problem showed up on later 4.x releases and was not around earlier. And again, it does not present on the Jack builds at all. I would assume that it has something to do with the code dealing with buffer size and sample rate, given that resetting the sample rate in real time immediately but temporarily fixes the problem.

It seems to make sense. Yesterday Im upgrade to kubuntu 24.10 and start using MU 4.4.3 beta. From there on I hadn't had any issue yet. I just don't which of these two upgrades is being helpful.

fernandomartin777 commented 4 days ago

This needs to be bumped to a different release project for now as it's proving to be extremely difficult to reproduce.

I left a comment describing how to reproduce it. All we need is a linux distro with pipewire natively. It worked in previous MU versions because pipewire was not implemented in several distros. As it is being now, MU 4.x audio is unusable with pipewire.

I was using prior M4 builds exclusively on Pipewire. I am also using the Jack PR on Pipewire. This problem (while it MAY be related to Pipewire... it is a new problem that did not exist on prior M4 builds). Be aware that distros like Ubuntu Studio run Pipewire by default at a sample rate of 48000. On previous M4 builds, you would have to set Pipewire to 44100 to allow M4 to work. The symptoms at that time were the same, but they started at the onset and could not be resolved without changing the system sample rate. So the symptoms now, with M4 running at any sample rate (which is the newer feature) produces a response that is identical to a sample rate mismatch... but it does so intermittently rather than consistently.

In previous version I tried to change the sample rate of pipewire but after some minutes audio started to stutter badly just as it happens now.

musescore / MuseScore