-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
[MU4 Issue] Soundplayback after note input noticeably delayed #16112
Comments
Forgot to mention: If there is anything I can do to help solve this, please let me know! |
Same here, everything fine with MS3 (parallel installation), huge lag with MS4 and now no sound at all regardless of the score size. Playback goes well with other audio programs (e.g. Logic). M1 Macbook Pro |
I have the same problem. Musescore 4 is useless to me because of the problem. OS: macOS 13.0, Arch.: x86_64, MuseScore version (64-bit): 4.0.1-230121751, revision: github-musescore-musescore-9b70a8c |
Same issue here on M2 Macbook Pro, macOS 13.2 |
I am also experiencing this issue, on an M1 Macbook Pro. I think an important question to answer is whether the delay is in input - the time it takes for the message to go from Perhaps that will help turn over the correct rocks. I unfortunately have no idea what I am doing! |
We did actually try to address this in #15010 (it was actually worse than it is now), however I agree that the problem still persists to a noticeable degree, and we should ultimately be aiming for no noticeable delay at all. |
I also want to strongly urge solving this issue: to bring it back to the way MU3 worked. |
I measured the latency from the button press to different parts of the processing chain:
So the majority of the latency is from the audio buffering, which cannot really be shortened too much or there would be stutter (this depends on the number of instruments in the score, regardless whether they are playing). In the audio worker thread, there is a 2ms sleep between processing calls. If I remove that, there is a bit more room for a shorter buffer, but not a lot. There is also a 20ms timer between receiving and processing the midi events, which could be shortened unless there is a particular reason for that delay. |
Thanks for looking into this @Jojo-1000! |
I have had the same problem and have stuck with version 3. I asked Marc Sabatella and while responding to his questions and suggestions, made some progress:
But then I changed one other thing. When I looked at Preferences - I/O, I noticed that the Audio device was set to "System Default". I changed that to the actual name of the default device, and the lagginess was reduced quite a bit - but MS Basic is still more responsive. So, with Properties displayed, the buffer size at 1024, and the Audio Device explicitly selected, the overall behavior is significantly better. MuseScore 3 is snappier, but I will now consider switching to the new version. This is in Windows 11 on a 4-year-old laptop with plenty of RAM (16 GB). I'm also just working with Piano music and can't say how I'd fare with an orchestral score. |
While I don't know enough (any) of the internals to claim with any authority that this is doable, could it not be possible to reconfigure the buffer size to a smaller one in situations where only a single instrument is active? For example when playing on the virtual piano (with no other playback going on at the same time) or when a channel has been set to Solo in the mixer panel. To me, these are the two situations where low latency is most critical (when playing back a full score with multiple instruments, not as much), and given that it's almost a full order of magnitude larger than the other sources of delay, it does not sound too unreasonable to have a special optimization for this scenario. |
So.... when is this being fixed? 4.4 now? In this thread, this issue was being prioritized for 4.1. This is an issue that's been here since 2.0. Like, please man. |
Some more measurements vs buffer size: My setup is garageband recording a loopback from another track synthesized by garageband, as well as the output of musescore. I built from source and added more buffer size options, all the way down to 32. The reported number is the time delta between the audio produced by garageband (always first) and the audio produced by musescore: 4096: ~440ms Note: The baseline delta between garageband recognizing midi input and garageband synthesizing an audio sample is ~60ms. So all the numbers above should have 60ms tacked on to get an "absolute" delay from the time you press the key (practically speaking). I'm using a Scarlett 2i4 on a mac pro M1. For a ~2x improvement, simply reducing the value of MINIMUM_BUFFER_SIZE in audiotypes.h to 64 would do the trick. However, IMO 170ms is still an unacceptably distracting amount of latency. Something else needs to happen as well. |
I joined just so I could add more to the conversion. There is a lively discussion about this on the musecore forums. I see lag as well, here are my details: Dell XPS 8960
Midi Keyboard used for testing: M-Audio Keystation 49es MKIII Also Present: Pro Tools (latest version) Basic Sound fonts have almost no lag, but Musesounds and VSTs have lag. Version 3.6 - zero lag, works amazingly When using a VST through Pro Tools or Studio one there is no Lag at all. Midi keyboard works like a charm. |
@ bill0287 commented
I believe this may be that lively discussion. |
Describe the bug
When entering a note - regardless of the input method and regardless of whether or not note input is enabled - the soundplayback is noticeably (~0,5secs) delayed. This makes trying out a line (or sth.) before writing it down impossible. This forces some users - including me - to continue using MU3 (see forums).
I've already tried a view things to narrow it down. It seems to be a general issue however. For details please see "Additional context" section below.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
When pressing a key on the MIDI keyboard or the on screen piano, the playback of the sound is near instantaneous (at or below around 20ms with a hardware like mine).
Screenshots
Platform information
Additional context
Below is a List of things I found out while trying to solve the issue on my own.
I've tried all that with the current Release Version of MU4 (4.0.1) and the latest nightly build (MuseScoreNightly-230280506-4.0.2-cfffaa1-x86_64). Behavior is the same in both versions.
Possible relations
This issue may be related to the following:
#15649
#15354
#13052
The text was updated successfully, but these errors were encountered: