You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have three ways we can try to sync the time Madmom reports with Spectrum.
In the initial version, for each beat, Madmom would report the number of seconds elapsed since the first detected beat. When we received that first detected beat on Spectrum, we would check the time, and then for each subsequent beat we would add the two numbers together. This had the issue of not accounting for any delay between the time Madmom reported and the time C# picked up the output
To try and address this, we changed the code to use absolute timestamps. Madmom would output the number of milliseconds since the system was booted. This is a purely monotonic number, avoiding NTP clock sync issues, which we get from time.monotonic(). We would then compare those numbers to what we saw from C#'s Environment.TickCount, which is supposed to output the same number, and to our knowledge is sourced from the same internal APIs. However, after implementing this solution, we saw an issue where the skew between the Madmom-reported time and C#-reported time (at the time of reading a new Madmom-reported beat) would steadily increase. However, when watching animations performed to music, Madmom still seemed to be triggering beats at the correct intervals
To address the skew issue described above on-playa, @revbucket changed the Madmom code so that instead of tracking the initial time.monotonic() and adding it on the reported elapsed time, we would just check time.monotonic() at every beat. I wasn't there to see whether this eliminated the clock skew issue, but Madmom did seem to perform well I can't find the code for this, see comment below
Ideally, I'd like to:
Understand why solution 2 above resulted in an increasing clock skew, and whether there is an issue with C# being increasingly delayed in picking up newly printed console lines from Madmom
Understand if solution 3 actually improved behavior over solution 2, given that both seemed to show well-synced animations
Ideally have C# actually compare its own readings from Environment.TickCount with what we get from Madmom
The text was updated successfully, but these errors were encountered:
I can't find the code for solution 3, either in the spectrum folder or the spectrum_new folder that we were running off of on playa. I know I discussed it in person with @revbucket, but it's possible he decided to forgo solution 3 given that solution 2 seemed to work okay, despite the steadily increasing clock skew
d9dae0a is the commit that added code to print the skew so we can watch it increase. Once we fix this issue we should revert that commit
I can confirm that the skew still steadily increases when running the current latest version of Spectrum (which incorporates solution 2 above)
We have three ways we can try to sync the time Madmom reports with Spectrum.
time.monotonic()
. We would then compare those numbers to what we saw from C#'sEnvironment.TickCount
, which is supposed to output the same number, and to our knowledge is sourced from the same internal APIs. However, after implementing this solution, we saw an issue where the skew between the Madmom-reported time and C#-reported time (at the time of reading a new Madmom-reported beat) would steadily increase. However, when watching animations performed to music, Madmom still seemed to be triggering beats at the correct intervalsTo address the skew issue described above on-playa, @revbucket changed the Madmom code so that instead of tracking the initialI can't find the code for this, see comment belowtime.monotonic()
and adding it on the reported elapsed time, we would just checktime.monotonic()
at every beat. I wasn't there to see whether this eliminated the clock skew issue, but Madmom did seem to perform wellIdeally, I'd like to:
Environment.TickCount
with what we get from MadmomThe text was updated successfully, but these errors were encountered: