Home Page Forums Other Emulator Message Boards Audio Overload AO SDK release 1.0 available

because you can do that only for around 6 hours. after that the post becomes definitive and you have to reply to yourself

p.s. thanks for the work on makaron

Yeah. Of course, mods can change your posts to say "what what in the butt" at any time.

I'm having some trouble getting DSP input levels right. Problem is the sample values in MIXS are well in range but DSP ends up heavily clipping the output anyway...
Seems like AO has this too, try listening to soa-367-04-00 with DSP output only and you should hear it hiss and die within seconds.

kingshriek, as I understand AO uses parts of MANATEE to play DSFs? Would it be possible to create some sort of patcher that would go over dumped RAM image and hack ARM program to mask DISDL writes to zero?
I'd like to test that soa-367-04-00 (and few other tunes as well) on Dreamcast, but with DSP output only. This way I could confirm if it's supposed to be that way or is it our DSP bug.

Might work to have the SH4 just constantly read all the slots' DISDL registers and zap them.

I'm not sure what is the correct way to handle this nor am I aware of any documentation that addresses this issue. I did look through a quick sampling of various ssfs and didn't see any meaningful DSP instructions where IWT==IRA.


Try replacing the following two consecutive instructions:


Instruction locations will vary based on the version of manatee.drv used but I would expect them to occur consecutively in most versions.

Hacking RAM image works as intended - and that is the only good news I bring. Dreamcast DSP output is stable, so it must be a bug.

This is what I get - upper track is Dreamcast DSP, lower is my player. I've ommitted AO because it's pretty much the same (there's slight variance on the time line but that's my code still lagging a tiny bit).

http://pics.livejournal.com/dknute/pic/000ba6dw

EDIT: And one more, perhaps important thing. This wave comes mostly from ADPCP type 2 looped sample. If the decoder adds an offset and the output shifts too much away from zero it could be the source of the problem. I'll need to test it some more though. Do note that the very beginnig of the sample seems to be OK, and the moment it goes wrong (dives down) is, if I'm not mistaken, loop jump.

Yet one more update. Seems like soa-367-04-00 program never sets NEGB to 1. If you do that (like, change "if (NEGB)" to "if (!NEGB)" the echo is gone but the output comes out clean. That gave me an idea, try this:


Much better I'd say. Good for a quick patch but I still need to find the source.

I'm giving up for the moment. I was never that good with signal processing anyway Some loose thoughts:
- as I understand it the accumulator multiplication is X (24b sample value) times Y (.12b signed fixed point)
- for the SOA tune it helps to scale Y down a bit (taken from COEF table)
- that still doesn't help all that much, and some other files still play wrong (like first Sakura Wars 4 one)
- if you scale down MIXS input, the sound will still be clipped and hiss, but won't die completly (wave looking wrong though, so it's not really about input level)

I've tried several modifications, like saturating v, v+B (note, those never get out of 26 bit range anyway). It doesn't seem to be memory read/write problem either - tested on separate table to store full ints rather then packed ones.

That particular SOA program is rather simple, all it does is take MIXS, read some memory, write some, use COEF only, writes output. No fancy addressing or latching registers. It does use MEMS and TEMP though. If you zero whole TEMP range on DSP step entry it behaves a bit like if you lowered MIXS level - sounds better but wave still going up and down and has clipped areas.
Based on this I'd say it's either ACC that is computed wrong or TEMP addressing is incorrect. I've tried many things on both, no results (like getting TEMP address just a bit wrong and you loose one or both sound channels). Perhaps there is a way to control MDEC_CT value?

I'll test few more silly ideas of mine but I don't expect any positive changes. If anyone wants to give it a try, be my guest. At this point I'm not touching DSP anymore unless something comes to me...

A bit of the funny: since we locked in the basically perfect SCSP in MAME and AO, Yabause and SSF have both had releases where the primary feature was debugging the SCSP. I'm making no accusations and the code's free and open to look at anyway, but it does make me laugh.

There's some complaints about the crash cymbal in Shining the Holy Ark (the SSF rip). In sha-03.minissf it looks like this:

StartSlot: SA 557f6 PCM8B 0 LPCTL 1 ALFOS 0 STWINH 0 TL 35 EFSDL 0
AR 1f D1R 0 D2R b RR 14 DL 0 KRS 0 EGHOLD 0 LPSLNK 0

I agree it sounds unnatural, but not enough that I wouldn't say it's potentially just poorly made. kingshriek, any ideas? If I understand the envelope correctly (and I'm not saying I do) it seems like correct behavior (it keys on full strength and stays there on a very short loop until it's explicitly keyed off).