digital-sound-antiques/emu8950

A Y8950/YM3526/YM3812 emulator written in C.

emu8950's Issues

Nuked-OPL3 drop-in replacement

hello, i am biting my teeth out trying to make emu8950 a drop-in replacement for nuked-opl3 in this simple app: https://github.com/cmdrf/droplay .
it is a player for dosbox' OPL captures in DRO format, so what it does is basically just feeding any recorded raw OPL commands to the OPL "chip", which in nuked's case is blackbox-like: the only interface are register writes whereas emu8950 has a way more sophisticated (and complicated) API. The reason i want to use emu8950 there is three-fold: 1) nuked produces a heavy CPU load, 2) it uses a LGPL license 3) my favorite tune https://github.com/Malvineous/dro2midi/blob/master/testcases/sango_fighter_title_drov2.dro plays some drums at about 0:22 which sound very bad with nuked, so i need to figure out whether the culprit is dosbox capturing an insufficient amount of state or nuked messing up the output due to some bug.

as for the difficulties i have with emu8950:

1. it's unclear why OPL_calcStereo returns 2 int32_t whereas OPL_calc returns an int16_t as expected and what to do to convert those into 16 bit samples
2. it's unclear what the difference between OPL_writeIO and OPL_writeReg is (at least to someone like me not very familiar with the intrinsics of sound chips)
3. how delays are to be treated and when to feed/read data into or out from the chip. i suspect i'll have to emulate the clock cycle timing of an MSX and in case of delays just grab a sample from the chip every X nanoseconds.
4. whether emu8950 needs additional setup data like this: https://github.com/Wohlstand/scc/blob/master/emidi_alpha/device/2413tone.h (the dosbox DRO format contains a capture of initial state of the OPL registers, so theoretically this should be sufficient)

i'd be glad for any hints you can provide, thanks!