In the old days, it sometimes happened that a computer with a compatible but faster CPU, had problems running old games. For example, Sopwith was written for an 8088 PC; it was amusingly challenging on a 286, completely unplayable on a 386. For a while, it was not unusual for PCs to have switchable clock speed (typically via a button labelled 'Turbo') to deal with this.
The proper solution, of course, was for games to start locking frame rate to the display refresh. That solution focuses on the display. What about sound?
The ideal scenario is a sound chip with a decent amount of autonomy, so it gets handed some stuff to play, and goes ahead and plays it without further intervention from the CPU. That both offloads work and avoids speed dependency.
But early computers didn't have such sophisticated technology. For example, the Apple II and the CoCo had sound hardware consisting of little more than a DAC, so the CPU had to be continually involved; doubling the clock speed would presumably be expected to double the pitch of the sound.
Are there any known cases, on any platform, where games did lock to the display refresh rate, but still had problems on faster machines, specifically because of the sound playing too fast?
Edit: As Michael Kjörling observes, the really proper solution is to synchronize display with the CRT refresh, while simultaneously using a separate timer as a way to time stuff happening. I'm not aware of anyone doing this before the nineties, but maybe some developers did. One reason it wasn't done in the eighties is that you can't strictly adhere to that discipline with a 2-D game because you can't really move things non-integral numbers of pixels.