Sound overhaul for TKG

[abu_the_monkey]

I can run it on the stock A4000 040 tomorrow evening if that helps.

[Karlos]

Originally Posted by abu_the_monkey

I can run it on the stock A4000 040 tomorrow evening if that helps.

It does. It would be very interesting if the shift normalisation is dramatically faster than the delta lookup since my expectation was that the lookup should be hitting the datacache at least every 15 out of 16 lookups. If that's not the case, I have some headscratching to do.

[Karlos]

The more I see of the 68060, the more I wish I'd gotten one back in the day.

[grond]

Originally Posted by Karlos

It does. It would be very interesting if the shift normalisation is dramatically faster than the delta lookup since my expectation was that the lookup should be hitting the datacache at least every 15 out of 16 lookups. If that's not the case, I have some headscratching to do.

I think the effect may be less because all the graphics data will have pushed out anything from the audio mixing by the next time you get into audio mixing. Then there will be a lot of reads from memory when you do the next bit of mixing before the cache can actually kick in.

[Karlos]

Originally Posted by grond

I think the effect may be less because all the graphics data will have pushed out anything from the audio mixing by the next time you get into audio mixing. Then there will be a lot of reads from memory when you do the next bit of mixing before the cache can actually kick in.

Well, that might be true in the game, but this is a standalone test program. There's nothing else to get into the datacache.

The way I'm doing stuff, I have all cache aligned data structures. We use move16 to transfer from sample data into a fetch buffer that we then operate on. The fetch and accumulation buffers are adjacent and cache aligned and so should be hot as soon as you've processed the first few samples. The only quasi random lookups are for converting the 8 bit samples to some volume scaled 16-bot one. This is what the delta encoding aims to improve. Almost all of the delta values are small enough to fit into a pair of cache lines. Only the first sample of 16 has to do a proper lookup.

The move16 operations are intended to avoid trashing the cache. The source data should not enter the cache and the destination location will be cached. We can even pre hint that if needed.

I am curious to see how these all perform on a faster 68040 implementation with local fast memory. The 3640 is useful for a worst case analysis since it has a relatively slow interface into memory.

[Karlos]

At the risk of seeming obsessed,I think I am going to add a "generic" version to this code that does not use any 040/060 specific operations (i.e. doesn't use the fetch buffer) and just reads the frame data directly from the sample source. We might get away with using the same mixer on 030, albeit with fewer input channels.

For that to be affordable, I'd probably want to have shift-only normalisation too.

[abu_the_monkey]

as requested.

[Karlos]

Originally Posted by abu_the_monkey

as requested.

Ta pet. I'll have a look after the footie

[Karlos]

A quick glance suggests it's only slightly faster, for what could be a pretty significant reduction in quality.

[abu_the_monkey]

Originally Posted by Karlos

A quick glance suggests it's only slightly faster, for what could be a pretty significant reduction in quality.

would it be better on an actual accelerator as opposed to a plain commodore processor card?

[Karlos]

Originally Posted by abu_the_monkey

would it be better on an actual accelerator as opposed to a plain commodore processor card?

I expect it to perform better, but I don't know how the trends will be affected. If everything is working as expected, all the code and important lookup data will be running from the CPU cache and the only memory access will be for the source sound data and for writing back to chip. The thought does occur, what if your test is dominated entirely by just fetching the source data? That should scale totally linearly with channel count.

[Karlos]

The 3640 results are a bit perplexing to me. I should do a null version that doesn't do any mixing or normalisation, but does fetch the source data and does push silence to chip. That'll give a baseline for all the data movement. If it's not very different then we can say it's memory interface issues

[daxb]

Maybe you should start a new thread for the 68040 testing issue. I guess most 040 user don't know or follow this thread. If my A1200 with Apollo 1240/40 would have network access I had already run the test.

[Karlos]

I didn't want to spam the forums with TKG specific threads

[patrik]

Originally Posted by Karlos

I didn't want to spam the forums with TKG specific threads

Interesting stuff and while originating in TKG, it is does feel applicable to general coding/optimization/68k cpu difference discussion etc.

[Karlos]

Originally Posted by patrik

Interesting stuff and while originating in TKG, it is does feel applicable to general coding/optimization/68k cpu difference discussion etc.

Do I hear a volunteer, old friend?

[patrik]

Originally Posted by Karlos

Do I hear a volunteer, old friend?

If you are asking for a 68040 machine with local fastram, I am afraid I have no such machine available . I have some 68000, 68030 and 68060 machines up and running.

[Karlos]

You guys are really going to make me power up my 1200 BlizzPPC040 tower, aren't you?

If the blue smoke comes out, I'm holding you all responsibile...

Who am I kidding, I didn't even put the HD back in when I imaged it a couple of years back

[patrik]

Originally Posted by Karlos

You guys are really going to make me power up my 1200 BlizzPPC040 tower, aren't you?

Looking forward to some BlizzPPC040 action

[Karlos]

Originally Posted by patrik

Looking forward to some BlizzPPC040 action

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