musescore
Sample Rate Retention Problem M4.4.X
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
@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
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)
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.
Problem persists in 4.4.4 on Linux. Devs don't seem to have a handle on the cause. Jack Transport branch continues to work fine, even when using Alsa.
My concern is that the Jack branch will eventually be merged to master and then the github PR project will close, leaving only the master with an unaddressed problem.
Can you give steps to reproduce this? I'm on Linux (Debian 12) using the official AppImages, and I have set my sample rate in Edit / Preferences / Audio & MIDI to 48. It's never moved since I set it there where 4.4 was first released. Is there some special series of steps I need to follow to cause the setting to be forgotten - presumably something that somehow deletes the INI files or whatever? Or maybe it's something special I have to set in my system;s audio configuration that somehow sends a signal to MuseScore Studio about changed preferences?
Can you give steps to reproduce this? I'm on Linux (Debian 12) using the official AppImages, and I have set my sample rate in Edit / Preferences / Audio & MIDI to 48. It's never moved since I set it there where 4.4 was first released. Is there some special series of steps I need to follow to cause the setting to be forgotten - presumably something that somehow deletes the INI files or whatever? Or maybe it's something special I have to set in my system;s audio configuration that somehow sends a signal to MuseScore Studio about changed preferences?
The only steps are general use. The sample rate does not change in the GUI settings when it happens, it merely behaves as if it has forgotten the sample rate that was set. I have to change the sample rate to a different one and then back again to stop the stuttering. It then comes back after some time of general use (usually minutes).
I was also wrong to say that the Jack branch doesn't do this when set to Alsa... I found last night that it does. But it never fails while on Jack (PipeWire).
I am guessing that the issue is specific to UbuntuStudio 24.04 and the configuration of Pipewire there. It also seems to happen under heavier processing (after some time of being open, while playing).
There's just no unique circumstances related to the occurrence, so I think this is why the problem is hard to find. I have already shared log files from several failures with the dev team, but they can't seem to spot the issue.
Hmm, seems to me to be more likely an issue with your audio system then. Like, even though MuseScore asked it to play a given sample rate, your audio device at some point changes back to another. Maybe because another applications takes control of it. Or do you have specific evidence that MuseScore is sending the audio at a sample rate different from the one it set?
Hmm, seems to me to be more likely an issue with your audio system then. Like, even though MuseScore asked it to play a given sample rate, your audio device at some point changes back to another. Maybe because another applications takes control of it. Or do you have specific evidence that MuseScore is sending the audio at a sample rate different from the one it set?
I have 4 machines and it happens on all of them. Each with different specs but the same OS and configuration.
Hi I have the same problem. I downloaded the last version of MS (4.5.1) and I still have the same problem (Ubuntu 24.04.2 LTS)
Hi I have the same problem. I downloaded the last version of MS (4.5.1) and I still have the same problem (Ubuntu 24.04.2 LTS)
Ultimately I ditched Ubuntu Studio 24.04.2 LTS and switched to Xubuntu 24.04.2 LTS MuseScore had become the core of what I do, so I made a sideways move away from the real-time kernel and Ubuntu Studio 48000 sample rate preconfiguration with Jack/Pipewire. The lightweight Xubuntu and simple Pipewire setup seems to be working fine at 44100.
I don't know why there are issues, but I know that Ubuntu Studio does not play nice with MuseScore 4. In fact, the distro has dropped MuseScore from their software suite (probably due to the nature of the appimage format and the proprietary Muse Sounds).
I am still able to run Qtractor through Pipewire and I run Ardour in Pulseaudio or Alsa Pipewire modes. With the new VLC sync plugin for MuseScore 4, I am able to achieve my film scoring objectives without Ubuntu Studio's special Jack configuration.
IMO, we shouldn't have to move distros to make MuseScore function... but that's what I did. Stuff needs to get done.
In kubuntu 24.10 when i to preferences in MU and set sample rate to 48000 it's working, at least currently.
I wouldn't be surprised if the Pipewire branch (if ever merged) resolves all of this. I had some success with that branch before switching OS, but the branch had other significant bugs in it from the builds that it was using, making it somewhat unfit. MuseScore should have a Pipewire specific support given the wide implementation of PW on Linux these days.
Hmm, seems to me to be more likely an issue with your audio system then. Like, even though MuseScore asked it to play a given sample rate, your audio device at some point changes back to another.
Ubuntu Studio ships with a pipewire configuration tool where I've set 44.1 kHz, 1024 samples, as recommended for MuseScore 4.
$ echo $PIPEWIRE_QUANTUM
1024/44100
I'm not changing this during a MuseScore session; however, multiple times an hour, playback gets choppy.
Workaround is to go to MuseScore's Preferences > Audio and flip to 48000 and back to 44100, then OK.
