MuseScore
MuseScore copied to clipboard
musescore
Stuttering playback on many systems with audio set to 48 kHz
Issue type
General playback bug
Bug description
On many systems, playback of MuseScore on any non-trivial score is extremely choppy, and somehow, just going to the device settings and changing the audio sample rate from 48 to 44.1 kHz almost always fixes it. The improvement is far too dramatic to be explained by 44.1 being ever so slightly less demanding on CPU/RAM than 48 - I think something is going more significantly wrong.
@bkunda I don't know how much exposure this problem has within the core team, but on the forums and in social media, I see it very often. We regularly get reports of people with similar audio issues, and we regularly tell them to try changing their sample rate to 44.1, and they regularly report back that it worked, but we also get people using this as an excuse to rant..
I suspect there is something going on where something is expecting 44.1 and something else is providing 48 (or vice versa), and in the attempt to reconcile the two through resampling or whatever, the sound gets chopped up.
On the off chance that this turns out to be something really simple like a missing parameter in a function call somewhere to honor the device sample rate directly and avoid extra conversions automatically, it would be awesome if someone could look into this!
Steps to reproduce
- Try to play any reasonably large score (especially with Muse Sounds but I am not sure that it's exclusive to that)
- In your OS settings, try setting sample rate to 48 vs 44.1 kHz
Result: on many systems, 44.1 sounds normal, 48 sounds terrible
Screenshots/Screen recordings
(I'll try to get screen recordings later from a system showing this)
MuseScore Version
OS: Debian GNU/Linux 11 (bullseye), Arch.: x86_64, MuseScore version (64-bit): 4.1.0-231921359, revision: github-musescore-musescore-2e3a93a
Regression
Yes, this used to work in MuseScore 3.x and now is broken
Operating system
Windows, Linux
Additional context
On the systems where the problem occurs, it occurs in all MU4 versions. The new reverb in 4.1 seems to help some, but still, 44.1 kHz performs much better than 48 on many systems - too much better to just be a matter of the slight reduction in the sample rate itself.
So far the vast majority of the reports are on Windows, which makes sense since that's where most users are. But also quite a few on Linux, and relatively few on macOS, which is interesting in itself. But conversely, reports of extreme lag between note input and sound being heard are more common on macOS, and I now wonder if this is somehow related.
There are some other issues relating to specific problems with sample rate settings (see for instance #18579, #17877, #17849, and especially #17313), and it's possible they will all turn out to have the same root cause, but right now there seems to be no other issue specifically covering a general issue with 48 kHz playback that is solved by changing to 44.1.
I for one am unable to reproduce any discernible difference when changing the sample rate on macOS.
I do perhaps detect the slightest difference when I do so on Win, but any stuttering I experience there is resolved by changing the buffer size (noticeable only in a particularly noisy passage in an especially large orchestral score).
Perhaps it might be related to the performance limitations of the system being used? For sure, we will need to test this further among the internal team to see how it can be reproduced.
As it's reported as being a general v.4 issue, it's something we can consider for the 4.2 project if we can get to the bottom of it.
@zacjansheski @DmitryArefiev this one will need further investigation.
Yeah, it definitely doesn't happen on all systems. But it's common enough - often more than once a day - that it does seem to indicate a real problem to me. Might be specific to some particular audio device/driver, might relate to some specific Windows patch or some particular Linux audio subsystem, etc. I recognize it's next to impossible to investigate without a specific system to reproduce it on, and if this were just a sporadic thing, I wouldn't bother opening an issue. But it seems pretty pervasive so I wanted to make sure we had a place to add information. I'll try to collect screen recordings and volunteers experiencing the problem who can run diagnostics etc.
FWIW, on my Linux systems - which are actually Chromebooks running Debian within a container - I do experience this, but to a lesser degree than what I've seen reported in the wild. And there is extra level of complexity in that ChromeOS itself doesn't provide control over sample rate; I can only do that within the container. So I'm pretty sure I'm going through some extra conversions no matter what, and thus my systems aren't great candidates for doing the sort of diagnostics I know we'd need. But I'm certainly willing to check out whatever I can.
I'd be interested to see if issues concerning playback at 48kHz start to become clearer once we start resolving the problems we know how to reproduce (e.g. https://github.com/musescore/MuseScore/issues/17877, which we've triaged as a P0 to get things moving asap).
If I add a log message in AudioModule::setupAudioWorker printing activeSpec.sampleRate, then it prints 44100 for me regardless of the current sample rate. Hard-coding 48000 for the parameter to the AudioEngine::setSampleRate call doesn’t fix the stutter when the sample rate is 48 kHz (and doesn’t cause the stutter when it’s 44.1 kHz, though it does stretch playback).
Also, setting the sampleRate property in the [io] section of the settings file to 48000 fixes the issue. So it’s most likely an issue with this property not being set to a supported value (instead using the default, 44100, if none is specified).
I have the issue on my machine, running Ubuntu and Pipewire. I reproduce the choppy playback as soon as MS sample rate is different than pipewire sample rate. I tested 4 configurations:
| Pipewire | MuseScore | Playback |
|---|---|---|
| 44100 | 44100 | OK |
| 44100 | 48000 | choppy |
| 48000 | 44100 | choppy |
| 48000 | 48000 | OK |
I don't know how to detect the "correct" config.
In LinuxAudioDriver::open, I added checks with snd_pcm_hw_params_test_rate.
It reports that both 44100 and 48000 are supported.
Which should be somehow. ALSA is normally able to resample to the correct rate.
@MarcSabatella is this issue still reproducing for you? And are you able to test it on anything other than Linux?
@DmitryArefiev and I have also been testing it and cannot reproduce (on either macOS or Linux).
It's definitely still an issue on Linux (4.3.2 and master), if audio is set up to only allow 48 kHz (which is the default on my system). I recently discovered that when using pipewire, all works fine if I set clock.allowed-rates to '[ 44100 48000 ]' - which is to say, if it is set up to allow applications to change the sample rate to 44.1 themselves, which is what I assume MuseScore Studio is trying to do. So that's my workaround currently - I leave the system rate at 48 but include 44.1 in the "allowed" rates so MuseScore Studio can set it that way (and presumably other programs could set it differently). Previously I was using clock.force-rate to force the rate to 44.1 system-wide. I assume other Linux audio systems have similar settings, but I'm not really an expert on how all that works.
Now, in current nightly builds from master, there is a new and significantly worse behavior, but with something of a silver lining. If I return my system to its default settings - 48 kHz system-wide, no 44.1 in the allowed rates - then not only is MuseScore Studio playback choppy, but also too fast and too high. 4.3.2 doesn't do that - the choppiness is the only symptom, and only in "big" scores, making it possible to believe it's a CPU or RAM or buffer size issue instead of a sample rate issue. The good ppsrt of this is, with 4.4 iut's more obvious exactly what is going on.
I notice there is a sample rate setting with MuseScore Studio that I can access via the DevTools panel, but the spinbox only accepts values up to 999. If I edit the ".ini" file directly, though, I can confirm as others have reported that setting 48000 allows it to work well using the default audio settings on my system.
As for Windows, we do still get reports pretty often about stuttering audio, and most of the time when we suggest changing audio sample rate, people report that fixes it - if they are able to figure out how to do it at all. Some people report that their audio device doesn't support any other rate but 48 kHz, and they often end up just giving up on MU4.
The reports of stuttering audio used to happen several times per day - literally hundreds of such reports over the first few months of MU4, on the forums, social media, etc. Now it's more like a couple per week. Hard to say if that slowdown is because 4.3.2 is better than 4.0 was, or just because there are fewer new users of MU4 than there were a year ago.
I don't have any issue with this on my own Windows computer, so I can't say if 4.4 works any better than 4.3.2 on the systems that are affected. I can try some more testing with a couple of other audio devices - but not sure when I'll be able to do.
I would add that independently of which systems show the problem with which audio systems, we can make all of our lives much simpler by exposing (and fixing the spinbox for) the sample rate setting within MuseScore Studio. Right now when the problem happens, it's really difficult to help people find the appropriate settings on their systems, and as I said, sometimes they hit a dead end (particularly Bluetooth devices often seen locked to 48 kHz). If we could just send them to Edit / Preferences we could make a whole lot of people much happier much more easily.
If that also allowed people to set 96 kHz - a very common request as well for people with external audio devices - then even better. That normally causes MuseScore Studio audio to play double speed an octave too high, as well as being choppy, and we get at least a report per week about that too. And these people don't like being told to downgrade their sample rate to 44.1.
Looks like all from 44.1 to 192 is expected to be(come?) supported. For reference, this is the setting with the .ini key: https://github.com/search?q=repo%3Amusescore%2FMuseScore+AUDIO_SAMPLE_RATE_KEY&type=code
I've tracked down on my system that this issue is caused by the Ubuntu Studio Audio Configuration tool which sets system-wide the PIPEWIRE_QUANTUM environment variable.
e.g. PIPEWIRE_QUANTUM="1024/48000" will force pipewire to convert ALSA output to 1024 samples at 48 kHz.
One having the same problem can delete this file: /etc/profile.d/ubuntustudio-pwjack.sh.
Or unset this variable from a terminal before starting MuseScore.
I guess unsetting from the application (one of the first thing in main) would also solve the issue.
Partially fixed by https://github.com/musescore/MuseScore/pull/23954, and also by #23736.
For the rest, we'll need to allocate time in another release cycle.
e.g. PIPEWIRE_QUANTUM="1024/48000" will force pipewire to convert ALSA output to 1024 samples at 48 kHz.
One having the same problem can delete this file: /etc/profile.d/ubuntustudio-pwjack.sh. Or unset this variable from a terminal before starting MuseScore.
Unsetting this variable when pipewire sample rate = 48kHz did not resolve the issue for me.
Using Ubuntu Studio Audio Config tool to set 1024 frames (or even 256 frames), 44100 kHz did work.
When using a pure JACK config, no Pipewire, I could not use the built-in audio at 44.1 kHz, so I suppose Pipewire is doing some upsampling in there. So it would be nice if MuseScore "just worked" at the user's choice of SR.
@MarcSabatella @jamshark70 Can you try the build from #23939 on you Linux system please?
Nice, seems to play smoothly at 44.1 or 48, even with a 1024 buffer size. Whereas the previous nightly build still stutters at 44.1.
FWIW, I am not sure what my audio configuration is. It's whatever the default is for the Debian container set up within ChromeOS. I know /usr/bin/pipewire is running and I am able to use some Pipewire tools, but I think the system is not really running Pipewire fully. I am pretty sure ALSA is involved as well, but again, maybe not fully. Whatever it is, it's probably actually just a front end for the ChromeOS audio system, which interfaces with Linux via a subsystem called "cras" (Chromium audio server). Or at least that is how it used to work.
@DmitryArefiev
Can you try the build from https://github.com/musescore/MuseScore/pull/23939 on you Linux system please?
Apologies, I overlooked this... was on holiday at that time, and then broke my leg 😮 literally just 2 days after you asked me to check this and I never got back to it.
Found the build and I'll run it for a few days, see how it goes. The issue happens quite frequently in the production build so I think it shouldn't take long to check it.
@DmitryArefiev AFAICS the new pipewire driver is working cleanly -- several hours' usage with no failures. Thanks!
However -- is there any chance that anything in #23939 breaks MIDI file export?
I just tried to export a part from a score to MIDI -- using the pipewire test build, no notes were exported. Using the production 4.5.2 build, MIDI export was fine.
Test build, could be anything -- just reporting this odd behavior with it.
There was a time where midi export was indeed broken in development builds. That PR is probably from that time, and has not been rebased since then, so the build doesn't contain the fix for that problem yet. But I don't think the PR itself is the cause.
