3 ms·
As an audio developer, making a timer metronome is the wrong approach. Still, many metronome apps with this design flaw exists and... they perform bad. (that's
by rock_artist 7y ago
As an audio developer, making a timer metronome is the wrong approach. Still, many metronome apps with this design flaw exists and... they perform bad.
(that's why prescheduled audio events works best...)
Timers in general will jitter.
Audio processing usually involves a callback to process an audio block (array of audio samples... floats).
To simplify things, this audio block runs on realtime thread and copies the block to desired output. you're guaranteed it'll be continuous between each call.
(you can cause overflow/stutter if you hold it for too long).
With setTimer approaches each callback WILL have offset.
But if you need to synchronize things or your metronome needs to run with other audio, it WILL be jerky.
That's why a proper metronome would also be 'sample accurate'.
WebAudio / AudioContext was made exactly to solve that!
similar to common audio processing standard, you end up getting a callback and usually need to use WebAsm/C++ under the hood to keep the golden DSP rule - never allocate on block processing callback.
btw, on Firefox 69 (macOS) only the pre-scheduled audio made a sound :)
- vnorilo 7y agoThis is completely true. I just want to add that the problem with currently standard WebAudio is that the audio callback still goes into the main js context/thread, so any custom callbacks via ScriptProcessorNode can be pre-empted by pretty much anything. That means that the target latency is the upper time bound for any js callback or work unit, and it gets really iffy when you approach real-ish time (10ms or so). The next attempt is AudioWorklet, which runs in a separate js context and on the audio thread. Sadly still exclusively in Chrome, so I can't be bothered to invest heavily in it.
- andoma 7y agoVery true. Another upside of deriving all timing from actual outputted samples: If your application have a sequencer which does "bouncing" (i.e. generating a recorded file, or similar, from the project) you can just run the sequencer as fast as possible in a loop which just writes audio to a file without any concerns about real time, etc.
- rock_artist 7y agoGood point. It really depends what’s the use case but as your suggested... time is relative. :)
- DoctorOetker 7y agocan WebAudio / AudioContext be used to regain precise timers for MeltDown etc timing attacks?
- padenot 7y agoYes, but mitigations have been in place for some time now.
- 52-6F-62 7y agoI'm not an audio developer (maybe aspiring in some ways?), but had to do some work for digital radio previously and my experience is similar. > btw, on Firefox 69 (macOS) only the pre-scheduled audio made a sound :) Also similar experience here, same version. Also "stop" didn't stop the pre-scheduled audio. It continued until 20 ticks.
- landonxjames 7y agoNot directly on topic, but I'm very interested in getting started in audio development. Any good suggestions for resources for someone with a strong math and programming background?
- rock_artist 7y agoI’ll start with JUCE (https://www.juce.com https://www.juce.com) just because it’s easy to get started. It’s similar to QT but oriented towards audio and can produce VST3/AU or audio apps pretty much out of the box. Once you get the hang of it it’s all about DSP. FFT, filter design etc. Also most actual DSP code is C/C++ depends on deployment needs. another approach is to try Faust, PureData. Look those up and see what’s looks as a good starting point for you.