Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

MIDI latency work #9

Open
jpcima opened this issue Sep 4, 2018 · 7 comments
Open

MIDI latency work #9

jpcima opened this issue Sep 4, 2018 · 7 comments

Comments

@jpcima
Copy link
Owner

jpcima commented Sep 4, 2018

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 typed double...
This particular problem seemed resolved, but latency problems were still present..
rtmidi-alsa.diff.gz

@jpcima
Copy link
Owner Author

jpcima commented Sep 4, 2018

I've made workarounds, now it's possible for winMM to work.
In the latency range which used by the standalone Windows software, adljack seems to work now better. But at higher latencies in 100ths ms, it becomes more and more crap as value goes up.

I've raised MIDI buffer size as necessary, because now it must have capacity for accumulation of MIDI events for a longer duration.
For now, MIDI input does not act in RT way, waiting to have available buffer space if it's full. No problem for ALSA MIDI, but in case of Jack, it can create xrun.

No work was pushed to the master branch, while ALSA remains broken and needs identifying the precise problem.

@Wohlstand
Copy link
Collaborator

I saw you have took some fixes into RtMidi library. Does this helps you to solve ALSA MIDI trouble with time stamps?

@jpcima
Copy link
Owner Author

jpcima commented Sep 17, 2018

At least, the timestamp don't emit crazy values at this point, but still some trouble remain.
I've not merged yet, into this adljack branch, the RtMidi patches I got accepted upstream.

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.

@jpcima
Copy link
Owner Author

jpcima commented Sep 17, 2018

@Wohlstand so, right now I merged in the timestamps code.
It's not perfect but I expect it to help the latency problem. Please give a try on your side.

@luzpaz
Copy link
Contributor

luzpaz commented Dec 5, 2023

CC @Wohlstand

@Wohlstand
Copy link
Collaborator

Wohlstand commented Dec 5, 2023

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.

@Wohlstand
Copy link
Collaborator

I forgot to say, a while ago I adjusted some internal delays, and problem has gone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants