First sound slightly softer

[KatieWoe]

Test device
Dell
Operating System
Win 10
Browser
Firefox
Problem description
For phetsims/qa#480. Only noticed on Firefox so far.
The first sound produced by the sim seems to be a bit softer than those produced after. Seems rather minor, may be in other sims as it is hard to notice. It does seem familiar, but I couldn't find another issue of it. Probably doesn't need addressing if hard to fix.
Steps to reproduce

1. Load/reload the sim
2. Click down on ruler
3. Lift up click off ruler
4. Repeat

Troubleshooting information:

!!!!! DO NOT EDIT !!!!!
Name: ‪Gravity Force Lab‬
URL: https://phet-dev.colorado.edu/html/gravity-force-lab/2.2.0-rc.2/phet/xhtml/gravity-force-lab_all.xhtml
Version: 2.2.0-rc.2 2020-02-13 23:11:52 UTC
Features missing: touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
Language: en-US
Window: 1536x750
Pixel Ratio: 2.5/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (Mozilla)
Vertex: attribs: 16 varying: 30 uniform: 4096
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 32767x32767
OES_texture_float: true
Dependencies JSON: {}

[zepumph]

This is sound related, over to @jbphet. Let me know if I can help.

[jbphet]

This behavior is due to the autoplay policy that is implemented by most browsers these days. This policy prevents sound from being played by a web page until the user interacts with it. There are a number of GitHub issues related to this, and perhaps the most relevant is phetsims/tambo#9. The particular behavior reported in this issue - i.e. that the first sound is somewhat soft - will happen any time the first action taken by a user produces a sound. I think the reason it happens is that the gain nodes associated with the audio contexts are turned up somewhat gradually, probably to avoid sudden, jolting sounds on the first interaction.

I thought about this a while back when I first noticed it in the Friction sim, and the only way I can think of to avoid the issue is to delay the initial sound. This wouldn't be super difficult, but it wouldn't be trivial either, and didn't seem to me to be worth the added complexity. It would also have the problem that the first sound might be noticeably delayed. @KatieWoe opined above that this "[p]robably doesn't need addressing if hard to fix". Given this input and the tradeoffs of addressing the problem, my recommendation is to just live with this, at least for now.

Back to you @zepumph since you're the publication lead on GFL. If you're okay with my recommendation, please close.

[zepumph]

That sounds really good to me. Over to @KatieWoe to document this for QA how she sees fit and/or close.