Audio mixer

Flexible, composable, fast, RSP-based audio mixer. More...

Files
file	mixer.c
	RSP Audio mixer.
file	samplebuffer.c
	Sample buffer.
file	wav64.c
	Support for WAV64 audio files.
file	xm64.c
	Efficient XM module player.
file	ym64.c
	Player for the .YM64 module format (Arkos Tracker 2)
file	mixer.h
	RSP Audio mixer.
file	samplebuffer.h
	Sample buffer.
file	wav64.h
	Support for WAV64 audio files.
file	xm64.h
	Efficient XM module player.
file	ym64.h
	Player for the .YM64 module format (Arkos Tracker 2)

Detailed Description

Flexible, composable, fast, RSP-based audio mixer.

This module offers a flexible API to mix and play up to 32 independent audio streams called "waveforms". It also supports resampling: each waveform can play at a different playback frequency, which in turn can be different from the final output frequency. The resampling and mixing is performed by a very efficient RSP microcode (see rsp_mixer.S).

The mixer exposes 32 channels that can be used to play different audio sources. An audio source is called a "waveform", and is represented by the type waveform_t. To be able to produce audio that can be mixed (eg: decompress and playback a MP3 file), the decoder/player code must implement a waveform_t.

waveform_t can be thought of as a "sample generator". The mixer does not force the whole audio stream to be decompressed in memory before playing, but rather work using callbacks: whenever new samples are required, a specific callback (defined in the waveform_t instance) is called, and the callback is expected to decompress and store a chunk of samples into a buffer provided by the mixer. This allows full decoupling between the mixer and the different audio players. Audio players are free to generate audio samples as they wish (eg: via RSP), as long as they honor the waveform_t protocol. See waveform_t for more information.

One of the main design goals for the mixer is to provide an efficient way to compose different audio sources. To achieve full flexibility without impacting speed, the mixer tries to honor the "CPU zero copy" design principle: samples are (almost) never touched or moved around with CPU. The whole API has been carefully designed so that audio players can produce samples directly into a mixer-provided buffer, so that the mixer can then resample and mix them on the RSP and store the final output stream directly in the final buffer which is sent via DMA to the N64 AI hardware DAC. In general, the N64 CPU is very bandwidth-limited on RDRAM accesses, so "touching" 44100 samples per second with the CPU would already consume too many resources. Audio players are expected to use RSP to produce the audio samples as well, so that the full audio pipeline can work totally off CPU.