Update pathname for the asm->src move

Reduce-Noise-and-Improve-Sound-Quality-(Implementing-a-New-Mixer).md

@@ -2,7 +2,7 @@ Many thanks to ipatix and Kurausukun. Without them, none of this would be possib
 
 Anyway, these changes will allow the game to have reduced noise and output sound at a higher base frequency.
 
-In [asm/m4a_1.s](https://github.com/pret/pokeemerald/blob/master/asm/m4a_1.s), replace everything in that file with the code in the link below:
+In [src/m4a_1.s](https://github.com/pret/pokeemerald/blob/master/src/m4a_1.s), replace everything in that file with the code in the link below:
 
 [Mixer code](https://gist.github.com/PlatinumMaster/86946d5066714e0d8443675e1c5e27f0)
 
@@ -75,7 +75,7 @@ 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](https://github.com/pret/pokeemerald/blob/master/constants/m4a_constants.inc#L3) and [include/gba/m4a_internal.h](https://github.com/pret/pokeemerald/blob/master/include/gba/m4a_internal.h#L152). 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 890](https://gist.github.com/ShinyDragonHunter/6571250991f4b0f560206e2201e27e55#file-m4a_1-s-L890) of our new `asm/m4a_1.s` file. 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:
+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 890](https://gist.github.com/ShinyDragonHunter/6571250991f4b0f560206e2201e27e55#file-m4a_1-s-L890) of our new `src/m4a_1.s` file. 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:
 ```asm
 mov r0, #0x85
 str r6, [r9, r0, lsl#5]