ds: Replace magic numbers in mixer by definitions

[AntonioND]

No description provided.

[AntonioND]

I've rebased and merged all changes of the C branch... except for this. I'm trying to understand why the new values don't match the old ones. I'm sure there's a reason for it, and maybe it was mentioned back in 2023, but can you tell me what's the reason, @Lorenzooone?

[Lorenzooone]

Ok, so... By taking a look at it: are the resulting values different by 1, if at all?
Talking about when using MIX_SOUND_TIMER_SET_256_HZ_VALUE and MIX_SOUND_TIMER_SET_194_8125_HZ_VALUE.
The other values should check out (unless a really big mistake is there and I did not see it).

EDIT: MIX_SOUND_TIMER_SET_194_8125_HZ_VALUE should check out as well. So it's only MIX_SOUND_TIMER_SET_256_HZ_VALUE.

If I remember correctly, we were discussing how to approximate these values.
Whether to go for a ROUND_CLOSEST or a CEIL approach.

Considering how these values are used to trigger the IRQ, I now think we should go with the CEIL approach. Which I think is how maxmod originally got the values it uses.
To be clear, if I left these values, they work fine. However, going for CEIL should be better.

EDIT2: There may be some cases with high CPU usage where CEIL is actually required, now that I think about it some more...

When it comes to mmMixerSetFreq and mmMixerMulFreq, these are precision changes.
The old functions were imprecise in getting the wanted frequency. That's the reason for the changes.
Though feel free to revert those, if needed.