gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

ASM > Strange algorithm..?

#164121 - Ruben - Tue Oct 21, 2008 7:26 am

Hey all.

OK, I don't know whether this should go under the audio section or here, but since it's more logical than anything else...

The basic idea of my "main" (mixing) algorithm is to multiply by the volumes like so..

value = (volume left OR (volume right LSL 16)) * sample
value &= ~((maximum channels-1) LSL 16) //32 channels max
value = value LSR (channel count bits) //5 bits for 32

Or more graphically...

Code:
     FFFFFFBC <- -44
MUL 007F 007F <- Volume
-------------
    DE43 DE44
BIC 001F 0000 <- (32-1)<<16
-------------
    DE40 DE44
LSR         5
-------------
    06F2 06F2


That's all OK and everything, but then comes a problem at the "final" (mix down) step.

Since I'm using a "fixed point multiplier" (the global volume) at the end to scale the values, anything that's >= 80h has no distortion, but anything BELOW that... ayayay! And also, I've got a problem for clamping (clipping), as I can't think of any conventional method to clip that. (Maximum value: 7Fh, minimum value: -80h)

EDIT:
Whoops. Wrong section. Can someone move it to coding or the appropriate one? Thanks.

#164132 - keldon - Tue Oct 21, 2008 5:45 pm

For clipping you can either brick wall limit (i.e. just apply max), or apply compression / soft limiting. Compression is basically reducing the volume of the chain when the level reaches the threshold; the attack and release are both gradual, reacting in around 1-6ms (or so).

p.s. you can't perform clipping with a bitwise AND. Oh, and are you losing 7 bits of precision with your "fixed point multiplier"? If so, you can calculate the result to 64bits and then downshift, iirc the ARM has a multiply that produces a 64 bit result.