4/5/2024 0 Comments Sonic visualiser filterIt’s still faster because it does so much less work for each increment. R2 has less widely-spaced distinct “modes”, because it uses smaller increments.R3’s long internal processing buffers and step size mean that it hops between “modes” depending on how many processing increments (1, 2, 3, 4 or occasionally 0) are required for each output block. R2 is usually faster, sometimes much faster, especially for modest stretch factors.The plots for R2 (orange) and R3 (purple) reveal significant differences in behaviour: In the first quadrant, the pitch rises smoothly and then falls again, reaching a peak at two octaves up in the second it falls smoothly and then rises again, reaching a trough at two octaves down in the third the pitch is unchanged but the tempo slows to just under a third of the original speed and then returns to normal and in the fourth quadrant the tempo gradually speeds up to 8x the original speed and then returns to normal. The test runs in four consecutive phases with different pitch and time modifications, and so the x-axis is divided into four (uneven) quadrants: raising pitch, lowering pitch, slowing down, and speeding up. Obviously the relative heights may also vary from system to system, so this is still quite tentative. No units are shown because they are totally system-dependent - this is purely a comparative visualisation, we’re only interested in the relative heights. The y-axis is linear in time with zero at the bottom, so lower is better. The results for R2 and R3, as of the 3.0 release, look like this: This is a graph of processing cycle count (x-axis) against time taken per 512-frame cycle (y-axis). The stretcher is initialised with typical parameters for this activity (in code terms, OptionProcessRealTime | OptionPitchHighConsistency | OptionFormantPreserved) and it is primed with an initial pad before entering the cycle loop, as otherwise the first call would dominate results. To measure this, I set up a test case that simulates a typical sound processing callback, passing a music recording through a stretcher and emitting a fixed 512 sample frames from each processing cycle, while varying the time and pitch ratios and measuring how long each cycle takes to return. Rubber Band is often used in real-time situations where the worst-case time per processed block is what matters most. Sustained throughput is not the only measure. Still, as it turns out, there are a few things we can do. It would be nice to do better, but the R3 code was already quite heavily optimised before release - it is simply a fairly CPU-intensive method. Both are eminently usable in real-time on hardware from the last decade, but the headroom available for R2 can make a big difference. Measuring sustained throughput in frames-per-second for common fixed stretch factors, we find R2 to be typically about three times as fast as R3. The older one is still included, and I’ll call that R2.Īlthough the output of R3 typically sounds much better than R2, it uses a lot more CPU power to run. In version 3.0 we introduced a totally new, higher-quality processing engine, which I’ll refer to as the R3 engine. This release focuses primarily on performance improvements. Today marks version 3.1 of the audio time-stretching and pitch-shifting library Rubber Band.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |