Audio (WIP branch)

[JayFoxRox]

Rebase onto #26 .

Related to #25 (but not compatible!)

---

FIXME: Move this to seperate PR

This code needs a lot of optimizations to produce realtime / enjoyable audio.

• VP feeds the GP
• GP feeds the EP
• EP feeds AC97

AC97 runs at a fixed samplerate of 48000 Hz and it's what the user hears. It must have the data at that rate. The data is only pushed at that rate if the APU (VP, GP and EP) runs at the proper speed.

The GP and EP each process 32 samples at a time. This means per GP / EP frame we have a budget of 32 / 48000 Hz = 666us.

So far, it looks like 60000 DSP instructions is barely enough to run a GP without effects. With the current DSP emulation the GP emulation alone takes about 5000us on my machine. Note that the EP or a fully loaded GP (many programmable sound effects at once) will be considerably more taxing - also this logic excludes any previous work by the VP.

I'm not sure why the DSP takes so long, it shouldn't do much more than setting up a couple of DMA transfers. If the DSP is really doing the amount of work it should we'll probably need a DSP JIT.

Eitherway, the GP and EP should be put on threads.

The VP also has to do some crazy amount of work. The ADPCM decoding should be optimized (it currently re-decodes the block beginning for each sample). Voices could also be generated on seperate threads or GPU.

Additionally our current threading runs at 10ms, so we miss the audio frames by a landslide. We can probably batch a couple of frames though.

---

FIXME:

• Split DSP EP fixes into a seperate PR
• Split DSP FIFO into a seperate PR
• Split VP emulation into a seperate PR
• Test interrupts
• Cleanup the buffer underrun stuff

[JayFoxRox]

FIXME

DSP: asr56 was actually lsr56. The flags / status stuff should be reviewed

Also check where S and L are set for shift operations (can't find it in the code, but spec asks for this)

[JayFoxRox]

FIXME

FIFO is implemented very poorly. It must use OFBASE0 / OFBASE1 / ... etc.

[JayFoxRox]

FIXME: Why does XQEMU GP output ringbuffer not advance?

Unsolved.. needs work

FIXME: Why are there weird 16 bit splits in ringbuffer output?

//edit: Works fine in smashing drive.. [30000 - 40000 cycles for GP] around 5149f0d // probably GP not having enough cycles?

[JayFoxRox]

FIXME: WAVEFORMAT only supports 2 channels, need to use WAVEFORMATEXTENSIBLE for the 6 and 32 channel output

[JayFoxRox]

@RadWolfie It is more or less complete. I'm still writing a tool to dump the internal ADPCM tables of the soundcard and I'll try to get the decoder bit accurate. But this is the current output of this branch:

https://cdn.discordapp.com/attachments/293096544549470208/329758397278978048/xqemu-smashing-drive-vp.ogg

(Which pretty much uses the same decoder)

[JayFoxRox]

FIXME: all of the above reviews are not done yet (despite github marking them as such)

FIXME: Add support for voice release

[JayFoxRox]

FIXME: Handle pauses for envelopes

[JayFoxRox]

FIXME: Optimize p:000b 0a8581 00000a (02 cyc) jclr #1,x:$ffffc5,p:$000a