Calling tone() right on startup results in a shorter duration audio

[arduino12]

Describe the bug
Calling tone() right on startup results in a shorter duration audio.

To Reproduce
Play this - and hear the first beep is shorter than the others.

Expected behavior
Both beeps play for the same duration.

Environment (please complete the following information):

• Windows
• Chrome

[urish]

This faithfully reproduces (after commenting out the delay(1000); at the beginning.

Looking at the virtual logic analyzer, it seems like the waveform is generated correctly:

So the problem is probably in web audio synthesis code

[arduino12]

Wow the logic analyzer is so cool!
This is my first time debugging a virtual hardware using a virtual test equipment..!

I tested using 500ms on 500ms off duration and I can also confirm the waveform looks right (from the logic analyzer view).
Also tried swappong from Arduino pin 8 to 9 and got same results.
Then I connected an LED in parallel to the speaker - and surprisingly its first blink looks shorter! just like the audio!

What do you think?

[urish]

Good job! Your little experiment pointed me at the right direction.

This is what happens: when you start the simulation, it doesn't know yet how fast your CPU runs. So it runs the simulation at maximum speed for a few milliseconds, and then uses that to estimate the slowdown factor.

The virtual logic analyzer uses the simulation time, not the real time. That's why everything looks good there. But since the simulation itself is running faster than real time for the first few milliseconds, you're getting a shorter tone / blink at the beginning.

[arduino12]

Happy to help!

LOL - great work finding the cause of this - it may solve other start-up related issues :)
Doesn't the simulation get the CPU speed from the json?

So it runs the simulation at maximum speed for a few milliseconds

When I try to change the quick-fix delay(1000); at startup to a lower value the bug remains - so I will stick with this for now :)
Anyway I will wait for the fix and try to test it again after.

[urish]

Doesn't the simulation get the CPU speed from the json?

It gets the speed of the simulated MCU. But it doesn't really know how faster your own processor is, as well as the environment (browser + OS). So it tries to run the simulation as fast as possible, and gradually slows down until it (hopefully) converges around 100% of real-time speed.

If you simulate an ATtiny85 running at 1MHz, the jump is even more pronounced. It can jump a few seconds into the simulation before the speed stabilizes.

Up to now, it hasn't really been a concern - you are the first person to find and report an issue related to this. So now I have a reason to look into how to improve it :)

[arduino12]

Ohh now I got it!

you are the first person to find and report an issue related to this.

Lucky me with my special talent to ruin the party by pointing out this kind of stuff ;)

Well good luck with this one! please let me and others know how you solved it here before closing the issue.
I will continue to play around with this beautiful simulator and I am sure you will bring it to perfection soon!

[urish]

This should be fixed now, thanks to change in how the simulation scheduler works.