Sound overhaul for TKG

[paraj]

Originally Posted by Karlos

I really don't think that'd be wise, tbh

Well, then don't threaten us with a good time BTW I would recommend some kind of solid state replacement for the spinning drive, but don't know what works in tower setup, for my normal wedge A1200 I use a CF->IDE adapter.

[Karlos]

What I really should use for it is a SCSI bridge. The BlizzPPC has a SCSI controller.

[paraj]

You don't have to get everything set up perfectly. Just enough to run timing tests. Even just a gotek drive would probably do for that if it's otherwise working OK.

Having some way of doing really cycle accurate measurements yourself is just so good/necessary/satisfying when you're theory crafting.

For "classic" A500 stuff I really wish I had a real (working) machine, but WinUAE is good enough for that. Even for plain A1200 it's just not accurate enough if you /really/ want the actual numbers.

[Karlos]

Any possible attempt to start up the 1200 would have to wait until the weekend. It did boot up last time I tried it a few years ago, but my old CRT has seen better days.

[abu_the_monkey]

I do have an A1200T with an apollo 1240@40mhz with 32mb fast memory in storage.

if I get the time I will dig it out.
it also has a CV643D so should work with the CF card from the stock A4000.

[abu_the_monkey]

@Karlos

what is the minimum required to run the test? will it fit on a floppy disk?
if the disk drive on the 1200T still works it would save pulling it apart.

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

what is the minimum required to run the test? will it fit on a floppy disk?
if the disk drive on the 1200T still works it would save pulling it apart.

Sure. Just the binary and the airstrike.raw sound file I think. It'll need to be in a directory called sounds but none of the other sounds are needed atm

[abu_the_monkey]

as requested, Apollo 1240@40 32mb

[paraj]

Great your doing these things @abu_the_monkey!

I haven't looked at the code (yet), but "Shift only" code path must be testing something other than I imagined.

[Karlos]

Originally Posted by paraj

Great your doing these things @abu_the_monkey!

I haven't looked at the code (yet), but "Shift only" code path must be testing something other than I imagined.

It should be testing the idea that we are just applying a channel volume as a shift, rather than doing it as a lookup or multiply. The code converts the 8-bit sample in the fetch buffer to a 16 bit one by sign extending it to 16 bit then doing a left shift. The shift size is in a register. It's just a fixed amount at the moment, rather than actually calculated based on the channel L/R volumes.

See: https://github.com/0xABADCAFE/tkg-mi...040_asm.s#L714

@abu_the_monkey

Looks like my delta code is worse now. I think it's the extra work per sample, so I will have to see what it is like if the samples are pre-encoded for it. That would make the innermost loop a few less instructions.

[Karlos]

Maybe it would go faster if I used the full register rather than using .w and maybe LSL rather than ASL, after all, once the 8 bit was sign extended, it shouldn't matter.

[Karlos]

If it turns out that for reasons unknown shifting is not as good as lookup (crazy but...), I say lookup has the key advantage of being functionally equivalent to the multiplication.

[abu_the_monkey]

Originally Posted by Karlos

If it turns out that for reasons unknown shitting is not as good as lookup (crazy but...), I say lookup has the key advantage of being functionally equivalent to the multiplication.

I can run it again to check it wasn't something I did during the test, but, I would have to wait till later this evening/tomorrow morning.

[Karlos]

Originally Posted by abu_the_monkey

I can run it again to check it wasn't something I did during the test, but, I would have to wait till later this evening/tomorrow morning.

I'm pretty sure that unless you decided to smash the CPU with something else halfway through, you didn't do anything to affect it.

I just realised I managed to type sh*tting and not shifting last time, lol

[paraj]

Don't think there's anything wrong with the testing, and can't see anything wrong with the code either.


I just don't understand how the shift version could possibly slower than the lookup method. It's a bit faster for 1 and 2 channels, but slower for 3+. I guess the cache is really helping the lookup for more channels, and there must be some kind of pipeline effect going on, but still.


Guess it really shows how one's intuition can be very wrong as soon as the CPU is even a bit more complicated than plain 68000.

[Karlos]

I'm going to add a null mix test and a preconverted delta version. Hopefully the latter is even better than the straight lookup. Only one way to find out.

[Karlos]

Here's the proposed mixing code for the pre-encoded L1 : D15 format

.mix_first_sample:
        move.b  (a3)+,d0         ; next 8-bit sample.
        move.w  (a2,d0.w*2),d4   ; look up the volume adjusted word
        add.w   d4,(a4)+         ; accumulate onto the target buffer
        
        ; d4 contains the current 16-bit value
.mix_next_sample:
        move.b  (a3)+,d0         ; next delta in d0
        add.w   (a2,d0.w*2),d4   ; add lookup adjusted delta to current
        add.w   d4,(a4)+         ; Accumulate
        dbra    d1,.mix_next_sample

If it's not faster than the linear version, I'm going to pack up and go and live in a cave...

[Karlos]

I've just pushed an updated version to test. It reorders the tests slightly to be a bit more logical

Test 0: Null Mixer - All source data fetches and chip data writes are performed (in the expected sizes and sequence), but no actual mixing or normalisation. This will hopefully give some sort of baseline for the IO aspect.

Test 1: The full multiplication path (060 target)

Test 2: The shift mixing path

Test 3: The 040 linear lookup path

Test 4: The 040 delta lookup path (on the fly delta)

Test 5: The 040 pre-encoded delta lookup

This last test preconverts the loaded data to ensure that the interaction with the tables (and thus the cache) is a realistic model.

[Karlos]

I should point out that I haven't strictly validated that the new method works but even if it has bugs, they're probably in the pre-encoder

[Karlos]

There was a bug in the pre-encoding, but not the actual mixer. In a completely unscientific test locally in UAE (no JIT), the pre-encoded version is basically the same speed as the linear version and faster than the on-the-fly delta. This is what I expect based purely on the number of operations per loop. How it performs on actual hardware, remains to be seen.

Changes are pushed.