I've looked into it further, and Julian is correct that cMuscleSpline is managing an internal cache of velocities. These are stored in the jiggleFrame attribute, which is a compound containing a force per control point per frame. The forces for a given frame are only updated if the time step is +1.

Assuming the cache is accurate up to x frames before the current frame, the jiggle offset for a control point can then be calculated using a standard wave equation. Any frame on which the input control point experienced an acceleration would spawn a jiggle wave which decays over time. Add up all the wave equations, evaluating each at the current point and time, and you've got your jiggle offset. Through some limited testing, I think cMuscleSpline is also applying a "drag force" opposite and proportional to the velocity in order to further offset the jiggle if the input control point is still in motion.

A few of the wave parameters are exposed to the user per control point (period (cycle), rest, and 3d amplitude). The remaining parameters can be calculated from velocity and acceleration as stored in the cache.

The only problem I see is how the cache stays up to date. Since the velocities are only re-calculated when the time change is +1, the cache can easily become invalid (i.e. if the animation was changed early in the timeline, but the user hasn't scrubbed over those frames). Ideally, cMuscleSpline would be able to detect when a cache has become invalid and use an MDGContext to re-calculate it as Julian suggested, but it appears that the 2010 implementation does not do this.