Open cfirwin3 opened 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 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?
Upload it to the comments
Upload it to the comments
Here it is. Found that GitHub wouldn't accept it without the .zip extension which was hidden on my system.
@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 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!
This needs to be bumped to a different release project for now as it's proving to be extremely difficult to reproduce.
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.
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 have the same behavior on a system without pipewire (Ubuntu 22.04)
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.
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)
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.
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.
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.
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.
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.
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