Updated Reduce Noise and Improve Sound Quality (Implementing a New Mixer) (markdown)

1 files changed, 3 insertions, 3 deletions

diff --git a/Reduce-Noise-and-Improve-Sound-Quality-(Implementing-a-New-Mixer).md b/Reduce-Noise-and-Improve-Sound-Quality-(Implementing-a-New-Mixer).md
index 1be555a..53137e6 100644
--- a/Reduce-Noise-and-Improve-Sound-Quality-(Implementing-a-New-Mixer).md
+++ b/Reduce-Noise-and-Improve-Sound-Quality-(Implementing-a-New-Mixer).md
@@ -75,11 +75,11 @@ Now all that's left, and this is optional as well, is fixing the reverb for your
 
 I talked about it like it's a huge deal, but there's actually not too much we need to change--in fact, the only thing that needs changing is the size of the direct sound buffer the game uses. This is defined in two different files--`constants/m4a_constants.inc` and `include/gba/m4a_internal.h`. Opening these files, you will see that the buffer's default size is 1584, or 0x630 in hex. Where does this number come from, you may ask--well it comes from the frame size I mentioned up above. The buffer is designed to last 7 frames in the game, plus some extra space at the end, so multiply your frame size to get the value you need. If we recall that the frame size of the default sample rate is 0xE0, we can do 0xE0 x 7, and we will find that it equals 0x620--which is 0x10 less than the original value (this is the extra space I mentioned). So find your sample rate in the table again, multiply it by 7, and replace the value in those two files with your new value. But we're not quite done yet!
 
-The last thing we need to do is update the mixer code to use this new value. By default, it uses a hardcoded 0x630 value to match the default buffer. Changing that is actually going to be harder than expected due to the way immediate values work in ARM. The statement in question can be found on line 963 of our new `asm/m4a_1.s`. If you're using anything under 36314Hz, you should be fine to just replace the value. However, for rates 36314 and above, the size of the buffer is too large to fit into the immediate field of a MOV instruction. Generally, the solution to this is finding values that can be bit-shifted to equal your new size. This works nicely for 36314's buffer size of 0x10A0--you'll find that 0x85 << 5 = 0x10A0. And luckily, ARM lets us bit-shift right in the operand, so we can do:
+The last thing we need to do is update the mixer code to use this new value. By default, it uses a hardcoded 0x630 value to match the default buffer. Changing that is actually going to be harder than expected due to the way immediate values work in ARM. The statement in question can be found on line 963 of our new `asm/m4a_1.s`. If you're using anything under 36314Hz, you should be fine to just replace the value. However, for rates 36314Hz and above, the size of the buffer is too large to fit into the immediate field of a MOV instruction. Generally, the solution to this is finding values that can be bit-shifted to equal your new size. This works nicely for 36314Hz's buffer size of 0x10A0--you'll find that 0x85 << 5 = 0x10A0. And luckily, ARM lets us bit-shift right in the operand, so we can do:
 ```
-MOV		R0, #0x85
+MOV	R0, #0x85
 STR     R6, [R9, R0, LSL#5]
 ```
-In place of the original STR command. For other values, you will need to find this on your own--Windows calculator's programmer mode is helpful for this.
+In place of the original STR command. For 40137Hz, 0x93 << 5 works. And for 42048Hz, you can do 0x134 << 4. Replace them just like the statement above, and you'll be good.
 
 And I believe that's that. If everything was done correctly (or I didn't screw something up), you will have much less noise in your sound.
\ No newline at end of file