The strategy of optimization is to start from the inner loops. We will get to the tracker soon but let me explain whats going on.
The deepest layer is the DAC. Pokitto has three ways of making an analog signal. A bit-by-bit dac_write, a masked dac write and a PWM dedicated to sound. Bit-by-bit DAC gives the cleanest sound by far, whereas PWM is better for pulse waves.
The second layer is the sound interrupt. There are three alternatives: pokSoundIRQ (synth & SD stream), audio_IRQ (Gamebuino sound & SD stream) and pokBufferedSoundIRQ (used at the moment only for SDFileSystem wav player test)
Up to this point it doesn’t matter where the sound data comes from. Its about making the inner loop as tight as possible because all mixing is real time. So if calculating one byte of sound takes say 100 cycles, were already talking millions of cycles per second for the sound.
Sd streaming is a great way to test the system, because you know from listening on pc what you’re supposed to get out. Any cracks / drops / glitches can be caught and it stresses the system to max
EDIT: …aaand I just realized I can optimize even further. We are doing zero latency byte by byte mixing at the moment, where every byte gets the function call overhead. If we accept latency (eg. 10ms, inaudible for human perception) we can process in chunks of 256 to 512 bytes at a time, removing the push / pop stack operations that are now done for each byte. That could save a lot of cycles.