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
Hydrogen version * : master, at least as far back as 2021
Operating system + version : eg. macOS
Audio driver + version : CoreAudio, PortAudio.
The playback track drifts slightly in timing when resampling to a differing output frame rate if the audio driver in use requests differing buffer sizes.
This is because the calculation of the offset into the sample from the global frame unnecessarily is unnecessarily quantized to the buffer size. If any previous call to processPlaybackTrack had a different buffer size, this quantized sample index is incorrect.
This didn't get spotted because unit tests of playback track only use the non-resampled case (the resampled case is untested there), the timing error is comparatively small (approximately a buffer size) and is only present on systems with variable-length audio processing periods (ie. not JACK or ALSA).
Fix incoming, which will be accompanied with a refactor in some other audio performance work I'm working on.
The text was updated successfully, but these errors were encountered:
cme
added a commit
to cme/hydrogen
that referenced
this issue
Dec 31, 2023
Hydrogen version * : master, at least as far back as 2021
Operating system + version : eg. macOS
Audio driver + version : CoreAudio, PortAudio.
The playback track drifts slightly in timing when resampling to a differing output frame rate if the audio driver in use requests differing buffer sizes.
This is because the calculation of the offset into the sample from the global frame unnecessarily is unnecessarily quantized to the buffer size. If any previous call to
processPlaybackTrack
had a different buffer size, this quantized sample index is incorrect.This didn't get spotted because unit tests of playback track only use the non-resampled case (the resampled case is untested there), the timing error is comparatively small (approximately a buffer size) and is only present on systems with variable-length audio processing periods (ie. not JACK or ALSA).
Fix incoming, which will be accompanied with a refactor in some other audio performance work I'm working on.
The text was updated successfully, but these errors were encountered: