-
Notifications
You must be signed in to change notification settings - Fork 3
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
MIDI latency work #9
Comments
I've made workarounds, now it's possible for winMM to work. I've raised MIDI buffer size as necessary, because now it must have capacity for accumulation of MIDI events for a longer duration. No work was pushed to the master branch, while ALSA remains broken and needs identifying the precise problem. |
I saw you have took some fixes into RtMidi library. Does this helps you to solve ALSA MIDI trouble with time stamps? |
At least, the timestamp don't emit crazy values at this point, but still some trouble remain. The last time tried, ALSA had still trouble despite patching, the midi event delays were not all well spaced at arrival. I think, I have demonstrated that RtMidi has a really weak point on timestamping and needs more fixing. However, the winMM situation is well improved, in the moderate buffer size values, such as upper bounds savihost has. Still, in the very high range (think 0.5s and up), the MIDI gets increasingly desynced, meaning still that something is wrong with damn timestamping. At one point, I should compare RtMidi vs Juce code in ADLplug, because that other manages to gets the timing all perfect without any troubles. |
@Wohlstand so, right now I merged in the timestamps code. |
CC @Wohlstand |
At some moment, I tweaked the code to resolve another problem that I found by myself that latency would get unexpectedly bloat and lead a crash later. |
I forgot to say, a while ago I adjusted some internal delays, and problem has gone. |
Feature request by @Wohlstand
Process in segmented buffers for latency reduction. A work was made in the
timestamps
branch.Problem
RtMidi sends wrong timestamps! 👿 The problem is present in different APIs. (ALSA, WinMM)
Certainly, the timestamping code is not very robust and needs rework..
At the first event with Wine and DirectSound, RtMidi can emit a timestamp
4292560.577000
seconds.In ALSA, there is seemingly a wrong calculation in a difference of
timespec
values...I converted the computation to using floating point, since after all
timeStamp
is typeddouble
...This particular problem seemed resolved, but latency problems were still present..
rtmidi-alsa.diff.gz
The text was updated successfully, but these errors were encountered: