I would also like to see a speed limit on volume increases, but no speed limit on volume decreases.

Note that the source of the problem is a combination of old encoders, debouncing problems, and CPU/disk timing issues.

The rotary encoder is actually interpreted as switches where each click is an up or a down. If the encoder is old/dirty, then it seems like more clicks are happening than there really are. Okay, that's problem one.

Debouncing is the code name for a software algorithm that tries to tell the difference between a dirty signal and a deliberate on/off/on sequence of switch presses. Sometimes the debounce logic isn't aggressive enough, especially as the switches age. That's problem two.

The third and final problem starts at the place the software tries to decide if you want a fast knob spin or a slow one. It says, "Okay, over the last X milliseconds, I've seen Y number of volume-up clicks." Then, depending on the ratio of X to Y, it increases the volume by Z amount.

But for some reason, if the player's CPU/disk is loaded down during that calculation, it doesn't seem to "get" all of the "clicks" over the longer time period. It seems like the clicks only hit the algorithm at the end, after the CPU/disk processing is done. So what the algorithm sees is all the clicks coming at once instead of seeing them appear spaced out over time. So Z in the calculation above is really big and it blasts you to death.

I think it would be cool if they could try and address the 2nd and 3rd problem somewhere during 3.0 alpha/beta...