The cycles don't (nor are intended to) match with a specific cpu speed.
if you use a different utility and you will see a different cycle count matching with the speed you want

first, what are you comparing to when you judge the sounds?

second, I don't have Karateka but you might want to try core=normal. This has helped me with some old/first-generation DOS games that show weird speedups / slowdowns in some parts.

like you I find that most XT-era games run best at a certain fixed speed (280 cycles for me), but there are exceptions. As Qbix said, you shouldn't rely on a benchmark / detection tool to provide a fixed cycle count for all games that assume a certain CPU speed - they all use different metrics and DOSBox isn't cycle-exact anyway.

however if there's no single config setting that produces a consistent behavior for the sounds AND the rest of the game, that's a different matter.

Thanks for your reply.

I set the cycles to about 190 to get the normally(by my memorization) sounds.
But the protagonist's motion becomes too slow(by my memorization, too).
So I ask for help here.

Since DOSBOX can't provide exact cycles/speed,
is there any way/utility to determine the best(as near as I want) cycles to run a game ?
Or I can only try and error and everything is decided on my memorization ?

mostly trial and error. There's a thread in the patches forum about setting the cycles to approximate a given cpu at a given clock speed, but all those numbers will only be approximate. With a real cpu, each instruction takes a different number of cycles to execute, and DOSbox doesn't account for all of that (not to mention fpu, video ram speed, etc). Early games used a whole variety of methods to set the speed... so these numbers can be useful, but no single "cycles" setting can really ensure that *every* 8088-era game (for example) would run at the proper speed.

the Karateka issue seems to be a different problem... you say that no setting gets both sound AND animation to run at the proper speed (either sound is too fast or animation is too slow), so any number of cycles would probably be useless unless a workaround is found.