Inconsistent Audio Output

[Inve1951]

On my machine WASM-4 produces inconsistent audio output.

Simple example cart:

const w4 = @import("wasm4.zig");
var tick: usize = 0;
export fn start() void {}
export fn update() void {
    tick += 1;
    switch (tick) {
        10 => {
            w4.tone(262, 60, 50, 8);
        },
        70 => {
            w4.tone(262, 60, 50, 8); // square
            w4.tone(262, 60, 50, 2); // triangle
        },
        130 => {
            w4.tone(262, 60, 50, 2);
        },
        else => {},
    }
}

About 1 in 3 times when loading (or reloading) this cart it plays completely different audio.
I can reproduce this issue in firefox and linux native. I have not tried other runtimes.

Audio Sample (linux native):

wasm4-audio-issue.mp4

I'm not sure what's going on here. Especially the middle note seems affected. Sometimes the distortion is subtle and sometimes it's very noticable, with a bit of randomness.

Pre-built Cart + HTML + Linux Binary:
binary.zip

WASM4 Version:
yesterday's master + my unrelated patches from #677 (history)

[JerwuQu]

This sounds like phase shenaningans (google phase cancellation), and the difference in audio when running the same cart would be because the phase of the channels aren't always consistent. The reason the differences happens is likely because rendering updates, meaning calls to update and hence calls to tone, don't happen on the same audio sample number every time you start WASM-4 (an inherent flaw in running the audio engine based on an inaccurate timer).

I'm not an emulator developer, but here are some fixes I can think of and what I think their downsides are.

The simplest fix for this particular case of variance would be to reset the phase to 0 every time a tone is triggered. This has a pretty nasty downside of giving audible pops if re-triggering a note though, since the phase gets shifted mid-sound. This is most clearly heard with the triangle channel, and I think there even was an issue/PR for it way back.

Another (albeit more difficult) fix would be to rewrite the audio engine's oscillators to go based on sample number for phase rather than having a separate phase variable for each channel. This would keep the same relative phase between channels, but the notes can still start at different points in the phase. I personally have no clue if this is a good idea.

Final solution is to make update completely based on the audio callbacks, making sure they always happen on a specific sample. This has the downside of latency. Either you have 1 frame of delay to "postpone" the actual updates for the next audio callback, always having the samples ready... or you make sure your sample buffer is large enough and your update function is always fast enough to deliver the samples, or you'll have missing samples resulting in crackling. I believe this version with 1 frame of delay is the only "real" solution since we can't know how fast or slow a WASM-4 game will be.

[majaha]

This is basically a natural product of combining two waves with the same frequency. It's pretty much what I'd expect from real 8-bit audio hardware (as someone with no real experience of it), so I don't think we should consider this a bug.

The "parametric phase" idea is okay, except that it would necessarily introduce shorter periods at the start of a tone. Maybe that wouldn't matter, maybe it would, but it seems kinda weird.

That said, I'm going to make a pull request soon that will probably change this behaviour to be much more consistent, at least when two tone()s are called in the same tick.