There is no separate DSP chip on AWE32/EMU8000 bearing cards, it is all part of the base chip. in case of AWE32 there's the EMU8000 which is a sampler with all the basic things one such thing should have and the DSP part is only the reverb/chorus bit that is applied to the final output which isn't more than a fairly traditional FIR filter setup. The coeffs are loaded as part of initialization even, with a table provided by Creative.

EMU10K in Live and its successors should contain an actual traditional DSP that runs some code and has operations specifically suited to do math on streams of data, whatever that data may be. It still is not an extra chip but part of the main chip.

Tiido wrote on 2021-12-28, 21:36:

There is no separate DSP chip on AWE32/EMU8000 bearing cards, it is all part of the base chip. in case of AWE32 there's the EMU8000 which is a sampler with all the basic things one such thing should have and the DSP part is only the reverb/chorus bit that is applied to the final output which isn't more than a fairly traditional FIR filter setup. The coeffs are loaded as part of initialization even, with a table provided by Creative.

EMU10K in Live and its successors should contain an actual traditional DSP that runs some code and has operations specifically suited to do math on streams of data, whatever that data may be. It still is not an extra chip but part of the main chip.

So what's the main purpose of EMU 8K/10K1 besides sound filtering.

the 8k is a wavetable chip, it plays samples, it pitch shifts, it has inbuilt effects (reverb, chorus etc). two lfo's for tremolo + vibrato.

the emu8000 IC doesnt have anything to do with midi really, it holds the base samples for GM compatability in ROM, but it doesnt 'process' midi internally, another cpu processes the MIDI commands and it tells the 8K which sample to play etc.

The AWE isn’t a MIDI card at all, just like the GUS. They are sample players, because it was maybe believed that hardware based music and sound effects playback would be more versatile and lead to better music (if you consider what was already possible with 4 sample voices on the Amiga). But the industry was already stuck with MIDI and if the GUS is any example, there was no will to adopt a new way of music creation (and the adoption of these kind of cards was very low also). There are just few games that use sample based music compared with how many games use MIDI.
But to come back to the AWE: it is no MIDI card, a game must either implement the MIDI driver in its own music driver (like DOOM) or you have to load the AWEUTIL TSR that emulates MIDI on your CPU.

the 8k is a wavetable chip, it plays samples, it pitch shifts, it has inbuilt effects (reverb, chorus etc). two lfo's for tremolo + vibrato

If I understood, EMU8k is responsible for playing wavetable samples of instruments pre-recorded in it's ROM, which happens when a MIDI playback is triggered from the main CPU by an application, right?

How were things different in the SB16 which has OPL3 (an FM synthesizer)?

And in both cards, how was non-MIDI sound achieved, like CD audio, what was responsible for processing in either SB16 and AWE32, for AWE32 was it again EMU8K or the "digital audio ssection"

it is no MIDI card, a game must either implement the MIDI driver in its own music driver (like DOOM) or you have to load the AWEUTIL TSR that emulates MIDI on your CPU.

How did the driver implementation help? Did it play the music in the EMU?

BEEN_Nath_58 wrote on 2021-12-29, 10:41:

How were things different in the SB16 which has OPL3 (an FM synthesizer)?

And in both cards, how was non-MIDI sound achieved, like CD audio, what was responsible for processing in either SB16 and AWE32, for AWE32 was it again EMU8K or the "digital audio ssection"

How did the driver implementation help? Did it play the music in the EMU?

the awe32 is just an SB16 with an E-MU 8801/8805 design added next to it on the pcb.

Dealing with the OPLFM was no different than on the SB16 or way back to SoundBlaster 1.
99% of the time the AWE32 was treated the exact same was an an SB16.

the block diagram shows how things interface.

BloodyCactus wrote on 2021-12-29, 13:42:

the awe32 is just an SB16 with an E-MU 8801/8805 design added next to it on the pcb. […]
Show full quote

BEEN_Nath_58 wrote on 2021-12-29, 10:41:

How were things different in the SB16 which has OPL3 (an FM synthesizer)?

And in both cards, how was non-MIDI sound achieved, like CD audio, what was responsible for processing in either SB16 and AWE32, for AWE32 was it again EMU8K or the "digital audio ssection"

How did the driver implementation help? Did it play the music in the EMU?

the awe32 is just an SB16 with an E-MU 8801/8805 design added next to it on the pcb.

Dealing with the OPLFM was no different than on the SB16 or way back to SoundBlaster 1.
99% of the time the AWE32 was treated the exact same was an an SB16.

the block diagram shows how things interface.

awe32bd.png

So far I got to understand the CT1748 (that thing for QSound), CT1745A (the mixer). Does EMU8K only play GM, and for SB16 music you have the CT1747 (Yamaha OPL3 FM synth)?
What's the CT1741?

the CT1741 is the 8052/80c52 embedded MCU that is the brain of the card.

A rough idea of what I got:

CT1745-A (mixer) is responsible for the mixer functions for the output/inputs.
CT1748A is responsible for QSound and for compressing/decompressing WAVs(PCM)
CT1747 does FM synthesis for SB16/AdLib mode games
CT1971(EMU8K) does sound post processing and also has General MIDI samples

but it doesnt 'process' midi internally, another cpu processes the MIDI commands and it tells the 8K which sample to play etc.

Did you refer to this 'brain' for CT1741?

BEEN_Nath_58 wrote on 2021-12-29, 10:41:

it is no MIDI card, a game must either implement the MIDI driver in its own music driver (like DOOM) or you have to load the AWEUTIL TSR that emulates MIDI on your CPU.

How did the driver implementation help? Did it play the music in the EMU?

Because the EMU does not do MIDI. It is a sophisticated sample player. You program it’s registers directly like a GUS or an Adlib card or like the SID chip of the C64. Therefore, you have to implement this logic in your software (like a driver) where the host CPU does all the hard work converting MIDI commands to playback of samples, including all voice management. Alternatively, you could be lazy and only support General MIDI output. Then you load a TSR that does the on-the-fly interpretation of MIDI commands to played back samples.