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

Hmm, this is the only reasonable fix that I can come up with:


This will push the crash cymbal sample immediately into the DECAY2 state, bypassing the troublesome zero-valued DECAY1.

Additionally, I've just discovered that using a different driver version fixes the problematic Shining the Holy Ark tracks (e.g. sha-07.minissf) where the SCSP-slot assignment gets derailed. I'm at a complete loss as to why the game's original driver is doing this in the rip.

You can get the "fixed" copy here for now:

http://h1.ripway.com/kingshriek/Shining_the_Holy_Ark.7z

It's rather difficult to compare my AEG code to what AO uses (many fundamental differences in timing and channel flag handling) but here's what I'm doing:


This is for the case when the current phase is ATTACK. As you see, I'm switching directly to Decay 2 if DL (I call it D2AEGP) permits it.
AFAIR this is what I observed on hardware. The switch to Release however will need at least one more sample, there is no direct route even if both Decay values are set to immediate.

As for slot assigments - sometime ago I belive I mentioned that AO seems to start playing with channel numbers in 0x2F range (rather then zero, like my player). Haven't really tested it since and it was alpha stage back then...
I still say you handle the key-on/off thing wrong (as in: hardware does it different way) and that could be the problem with the driver. This shouldn't have such effect though, I'd be rather expecting "ghost" (repeats) or incompletly defined sounds to appear - since you allow the channel to be keyed on in situations where it should not be possible.
But then again this doesn't seem to be happening so far, I guess nobody is trying to pull such dirty tricks on AICA

EDIT: Seems like the board doesn't like non-latin letters much. Fixed. And some nasty typos too.

Ahh, it sounds much nicer with the patch

SDK is updated with that patch.

DK: the exact same voices with the exact same parameters are keyed on between our cores, it's just they're on different slots. (And I've not seen such an effect with the SCSP). Probably they use timer ticks to seed the slot allocation or something.

This was just a wild guess. I'm simply pointing out things, since I'm too lazy to investigate myself

That's ok, meanwhile I've realized I should apply that envelope change to the AICA too.

some piece of "eng_dsf" code need clarification:
1)
if(slot->mslc)
{
AICA->udata.data[0x12/2] = addr1; // 2812 has no description. only 2814 contains monitored channel position (CA). so what's the purpose of 0x2812 ?
if (!(AFSEL(AICA)))
{
AICA->udata.data[0x10/2] |= slot->EG.state<<13;
AICA->udata.data[0x10/2] |= 0x3FF - (slot->EG.volume>>EG_SHIFT);
}
}

2)where is no "voff" checking (channelOffset + 0x28 bit 6 - according to great Neill Corlett's notes).

3)aosdk 1.4.1 handles 0x2892 & 0x2894 address for TimerB & TimerC instead of 0x2894 & 0x2898.

1) Probably a bug. CA is used mostly for ADPCM streams, so this has little impact on AO I guess.
2) & 3) - those are never used anyway

I was gonna say, the fact that something uses timers B/C is bigger news than our mishandling of them I'll fix it anyway though.