Get smooth, consistent output level changes to work

[jbphet]

Due to some issues with sounds being audible during startup and behaving differently on different platforms, I changed a number methods used to set gain changes to use linearRampToValueAtTime instead of setTargetAtTime. The issues that were being addressed were phetsims/friction#159 and phetsims/resistance-in-a-wire#205 (among, I think, some others).

Using the linearRampToValueAtTime method is turning out to cause some problems of its own, mostly in situations where a lot of changes are being made quickly, see phetsims/john-travoltage#329.

We need the ability to set the output level for tambo sound generators such that the sounds:

• don't allow sounds to play during load time or initial creation of a sound generator
• support frequent updates to the output level such that the volume changes are smooth and not jittery
• doesn't cause clicks and glitches when changing the output level

[jbphet]

As an initial step, I think it would be worth the time to create a standalone HTML file that tests the behavior of these methods on any browser.

[jbphet]

I've created a standalone HTML file that allows the user to turn on and off a sound source and then modify the gain using various APIs. Testing with this definitely shows differences in the way the Web Audio API behaves in several use cases. I've contacted the W3C Audio group and asked them what they recommend for how to work with the various browser vendors to help the implementations to get more consistent.

[jbphet]

I think I have some changes in place that should address both the problems with smooth changes and the problem where, due to differences in the implementation of setTargetAtTime between browser, sound could be heard at started. I could use some help verifying that this is fixed. Here's what needs to be tested:

• Test the master version of the friction sim on all supported platforms, verify that no sound is played during sim loading and that all the intended sounds play (you might need to compare with published versions to verify what sounds should play when).
• Same test for John Travoltage

[KatieWoe]

Making a list here for checking the supported platforms:

• iOS 11
• iOS 12

---

• Mac 10.10 safari

---

• Mac 10.11 safari
• Mac 10.11 chrome
• Mac 10.11 firefox

---

• Mac 10.12 safari
• Mac 10.12 chrome
• Mac 10.12 firefox

---

• Mac 10.13 safari
• Mac 10.13 chrome
• Mac 10.13 firefox

---

• Mac 10.14 safari
• Mac 10.14 chrome
• Mac 10.14 firefox

---

• Win 7 IE
• Win 7 chrome
• Win 7 firefox

---

• Win 10 Edge
• Win 10 chrome
• Win 10 firefox

---

• Chrome OS

[KatieWoe]

These two issues are relevant to the above testing.
phetsims/resistance-in-a-wire#205
phetsims/friction#159

[KatieWoe]

@jbphet Here are some problems I've seen so far:
On Win 7 Chrome Friction: Put on enhanced sound, refresh the page while the "shhh" is playing, click on the book and a bit of the "shhh" will play. (Edit: same on JT)
On chrome at least: After refreshing the sim, turn on enhanced sound, drag the book to increase temp, "shhh" will not play. It will the second time you try. Edit: seen on Mac safari as well, though not all for some reason. It happened on 10.12, but not 10.11. Also happened on iOS 11 safari

[KatieWoe]

QA is done. In addition to #61 (comment), I heard some instances of pops/crackles that were also sometimes present in the published version. This was not dependent on platform/browser. Finally, there were a few seemingly unrelated issues with keyboard nav in Friction that I discussed with @jessegreenberg

[jbphet]

I have an idea on how to test the behavior of the gain stages fairly rigorously. I could create a sound file that just has a constant (i.e. DC) output value of 1.0 and use it in an AudioBufferSourceNode, hook it up to a gain node, and then connect the gain node to an AudioWorkletNode that outputs the values seen in the audio signal. With this, I could see exactly how the gain node transforms the incoming value, which would be fixed at 1.0. I could lean on the work done for the peak detector to create this worklet (see #133) that would log the data. To avoid overwhelming the console, it could only log values that changed versus the previous value. Using this, I should be able to gather numeric data on exactly how the gain node behaves on the various browsers and using the various methods for changing the gain value, and then use that information to choose the approach that is most consistent across browsers and that sounds the best.

[jbphet]

This issue has been idle for a long time, and there haven't been any complaints about the way the gain changes work in the tambo lib. I'm unlikely to be in a position where I will have additional time to spend on this, so I'll just close it, and will create new issues if and when problems are reported.