I don't get this sequence of values. I see something like

delta sample = 768
delta sample 1024
delta sample 768
delta sample 768
delta sample 768
delta sample 768
delta sample 768
delta sample 768
delta sample 768
delta sample 1024

If you print out ctx.currentTime along with the delta values, you'll see that the the calls to render are usually 16 ms apart, but not always.  I see some that are 21.3 ms apart.

I think that is to be expected.  requestAnimationFrame doesn't guarantee that the calls are all exactly 16 ms apart.  They usually are, but not always.

And the delta value of 1024 at 48000 corresponds to 21.3 ms, as expected when the currentTime changes by 21.3 ms.

I guess your chromium uses period_size 256, and mine uses 2048.
What OS/audio backend you use?

Note that I use alsa dmix output (with fixed audio period_size).
When I decrease period_size to 128 (previously it is 960). Here the result:
chromium:
delta sample = 2048
delta sample = 0
delta sample = 2048
delta sample = 0
delta sample = 0
delta sample = 2048
delta sample = 0
delta sample = 2048
...

firefox:
delta sample = 768
delta sample = 640
delta sample = 1024
delta sample = 768
delta sample = 768
delta sample = 896
...

Lowering period_size makes audio timing in firefox more accurate, but has no effect on my chrome (Seem that it uses fixed 2048 period_size).

Note that requestAnimationFrame is called nearly smooth at ~16ms (use performance.now())

So is it possible to decrease period_size?
Or better, is it possible that audio timing accuracy is not bound by period_size?

Thank's.

Audio buffer size is set to 2048 because of https://bugs.chromium.org/p/chromium/issues/detail?id=178626

Manually decreasing --audio-buffer-size makes delta samples more smooth.

--audio-buffer-size=2048
delta sample = 2048
delta sample = 0
delta sample = 0
delta sample = 2048
delta sample = 0
delta sample = 2048
delta sample = 0
delta sample = 0
delta sample = 2048
delta sample = 0

--audio-buffer-size=1024
delta sample = 1024
delta sample = 1024
delta sample = 1024
delta sample = 1024
delta sample = 0
delta sample = 1024
delta sample = 1024
delta sample = 1024
delta sample = 0

--audio-buffer-size=512
delta sample = 1024
delta sample = 1024
delta sample = 512
delta sample = 1024
delta sample = 512
delta sample = 1024
delta sample = 512
delta sample = 1024
delta sample = 512

--audio-buffer-size=256
delta sample = 1024
delta sample = 768
delta sample = 768
delta sample = 768
delta sample = 768
delta sample = 768
delta sample = 768
delta sample = 768
delta sample = 1024

--audio-buffer-size=128
delta sample = 896
delta sample = 768
delta sample = 768
delta sample = 768
delta sample = 896
delta sample = 768
delta sample = 768
delta sample = 768
delta sample = 896
delta sample = 768
delta sample = 768

I was running the original tests on macos where the webaudio buffer size is 256.  On my Linux box (where the size is 512) I get:

delta sample = 0
delta sample = 511
delta sample = 512
delta sample = 1024
delta sample = 512
delta sample = 1024
delta sample = 512
delta sample = 512
delta sample = 1024
delta sample = 512
delta sample = 512
delta sample = 1024
delta sample = 1024
delta sample = 512

Better than what you see but similar to what you get with --audio-buffer-size=512.

Can I ask what the actual usecase is?  Are you really depending on the time data to be consistently increasing on each call?

I'm not sure if we can fix this completely since the animation clock and audio clock are almost always using different (unsynchronized) clocks which will drift.  This is what AudioContext.getOutputTimeStamp() is intended to solve.

> Can I ask what the actual usecase is?

https://mfcc64.github.io/html5-showcqtbar/
With audio buffer size 2048, the animation looks jagged.

> Are you really depending on the time data to be consistently increasing on each call?

Not so. With audio buffer size 512, the animation looks smooth enough.
So, is it possible to decrease default audio buffer size to 256 or 512 (alsa)? Because it seems that https://bugs.chromium.org/p/chromium/issues/detail?id=178626 prohibited using small audio buffer.

>  This is what AudioContext.getOutputTimeStamp() is intended to solve.

Nice feature.
The result (w buffer size 2048):
delta sample = 792
delta sample = 815
delta sample = 796
delta sample = 822
delta sample = 791
delta sample = 797
delta sample = 757
delta sample = 796
delta sample = 839

but occasionally I get:
delta sample = 806
delta sample = 87
delta sample = 1533
delta sample = 803
delta sample = 799

Deleted: jagged.html 1.8 KB

jagged.html 1.8 KB View Download

rAF operates at 16.6666 ms boundaries (probably alternates between 16.6 and 16.7 or so to average out to 16.6666...ms).  Let's assume we setup WebAudio to use 128 sample processing, the lowest possible.  Then each call to rAF is 2.1333... blocks.  Then the AnalyserNode will have either generated just 2 blocks usually or maybe 3 once in while.  The delta sample must vary; it can't be completely constant.

If you truly want consistency, you need to process "within" the audio graph, more or less.  This can be achieved using a ScriptProcessorNode or AudioWorkletNode where you can get the time domain data as it goes through the audio graph.  You'll have to synchronize this to rAF, but that is under your control, so you can do what's necessary.

I don't think you can do what you want with an AnalyserNode.  

I don't need strict consistency. Lowering audio buffer is enough. Currently, I use alsa and set --audio-buffer-size=512. Audio works fine, I don't find audio clicking.

I thought the default buffer size was already 512.

So everything is working ok?  (I'm not really sure what this bug is about anymore.)

No, I use alsa without pulseaudio. The default buffer size is 2048. See  issue 178626 

Hmm. I thought pulseaudio was a requirement, but perhaps not.

+dalecurtis for the definitive answer on that.

Pulse audio is not required, we will use ALSA w/o PulseAudio, but performance is generally quite bad (metrics show drastically increased glith counts), so the buffer size defaults to high.

I don't hear glitch, even with --audio-buffer-size=128. Probably, performance of alsa now has been improved.  Issue 178626  was almost 4 years ago.

I'll leave the buffer size issue for Alsa for dale to comment on.

But in this case, there's nothing really to be done here in terms of WebAudio, right?

Right.

Filed  issue 800847  for the alsa buffer issue. I'll let Dale figure out what to do about that, if anything.

Based on c#15, closing this issue.