[2.0.60] Programmable Speakers can skip 1 tick sounds

[B3tah3]

I built a speaker that plays an instrument sound for 1 tick every 20 ticks.
The timing of the heard sounds seem a bit random. Some sounds are skipped, and the durations of a note is between 10ms to 25ms, so from half a tick to 1.5 ticks.
I would expect for each sound to play for 1000/60 = 16.6 milliseconds. The expected duration between two notes is 20 ticks (333ms, or 16000 samples for my 48.000 Hz OBS recording.). However these are the intervals of note endings we measured:
15606, 16158, 16169, 15597, 16720, 15607, 32318, 32327, 16156, 16161, 15604, 16161, 16161, 16162, 15598, 16165, 16117, 15649, 16168, 16155, 15609, 16713, 15570, 32347, 15616, 16158, 16167, 15603, 16156, 16161, 15604, 16161, 16160, 16161, 15603, 16169, 16154, 15612, 16154, 16155, 15609, 33367, 15680,

This seems to happen randomly, but at 60 ups around 10% of the time. With the speed control mod at 120ups, it happens more often (~20% of notes).

[Donion]

First thing, when I load your save, the speaker doesn't play the last note in the sequence regardless.

Otherwise, with sounds playing just one tick you're on the limit of our audio system latency limit. By default the audio is mixed in chunks of roughly ~11.6 ms and the audio thread is in no way synchronized with the game update. What I believe you're experiencing is that the speaker calls to start playing a sound but due to the audio latency it is stopped in the next update tick before it actually starts playing (before the audio thread mixes it in). Since the audio thread is running freely, when this happens is random and happens more often as you speed the game up (and shouldn't happen if you slow the game down enough).

Tick precise audio timing is simply not possible.

Edit: if you haven't already, you can read this thread which touches on this.

[mmmPI]

I saw the topic linked and recognized it x) I read this one because i wanted to know more there are still some things i don't understand, that picked my interest and i will run further experiment on the blueprint

[B3tah3]

Thanks for the reply! I feared it might be because of these technical audio limitations.
I'm trying to use this for an mp3 player, where I preprocess an audio file into the amplitudes of many speakers (at different pitches and sounds), playing a new packet every update tick.
What might work is never stopping the speaker, but only changing the amplitude and volume every tick or every other tick. I will do some further testing on this.

[Donion]

Feel free to post findings from your experiments (maybe in the linked thread) but setting volume is limited by the audio latency in the same way as starting and stopping sound (any audio operation, really). Doing so every other tick (or more) should help but there will never be any guarantees about timing (that's why my variable music system is using mostly separate custom handling where audio samples are queued, but this is not available to the programmable speaker).