1226481 - Audio Cracking in Star Citizen Map

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Martin Best (:mbest)]

https://robertsspaceindustries.com/starmap?location=KALLIS&camera=60,9.67,0.0007,0,0

click on the sun, here the cracking when the zoom in sounds play.  Zoom out by hitting the back button and here the cracking.

This is not present in other browsers.

Comment 1

[Paul Adenot (:padenot)]

It might be because we don't implement de-zippering, I'm investigating.

Comment 2

[Maire Reavy [:mreavy]]

Paul, I'm making this investigation a P1, rank 7 (pretty high priority).  Once you know what the cause is, how likely the problem is to hit, and what our options are to address/fix it, we should discuss and reevaluate. Thanks!

Comment 3

[Karl Tomlinson (:karlt)]

(In reply to Paul Adenot (:padenot) from comment #1)
> It might be because we don't implement de-zippering, I'm investigating.

Yes:

Click on (invisible) Kallis star to view:
124.427029: gain for 23 SetValue value=1 time=0.000000 constant=0
124.427029: AudioBufferSourceNode 72 Connect() to GainNode 23
124.427029: AudioBufferSourceNode 72 Start(0.000000, 0, 2.22507e-308)
124.879819: gain for 24 SetValue value=1 time=0.000000 constant=0
124.879819: AudioBufferSourceNode 73 Connect() to GainNode 24
124.879819: AudioBufferSourceNode 73 Start(0.000000, 0, 2.22507e-308)
124.995918: gain for 23 SetValue value=1 time=0.000000 constant=0
124.995918: AudioBufferSourceNode 74 Connect() to GainNode 23
124.995918: AudioBufferSourceNode 74 Start(0.000000, 0, 2.22507e-308)
125.260045: gain for 24 SetValue value=1 time=0.000000 constant=0
125.260045: AudioBufferSourceNode 75 Connect() to GainNode 24
125.260045: AudioBufferSourceNode 75 Start(0.000000, 0, 2.22507e-308)
125.260045: gain for 44 SetValue value=1 time=0.000000 constant=0
125.260045: AudioBufferSourceNode 76 Connect() to GainNode 44
125.260045: gain for 44 SetValue value=0 time=0.000000 constant=0
125.260045: AudioBufferSourceNode 76 Start(0.000000, 0, 2.22507e-308)
125.260045: gain for 44 SetValue value=0 time=0.000000 constant=0
125.260045: gain for 23 SetValue value=1 time=0.000000 constant=0
125.260045: AudioBufferSourceNode 77 Connect() to GainNode 23
125.260045: AudioBufferSourceNode 77 Start(0.000000, 0, 2.22507e-308)
125.350023: gain for 44 SetValue value=0.185 time=0.000000 constant=0
125.442902: gain for 44 SetValue value=0.65 time=0.000000 constant=0
125.541587: gain for 44 SetValue value=1 time=0.000000 constant=0
125.855057: gain for 24 SetValue value=1 time=0.000000 constant=0
125.855057: AudioBufferSourceNode 78 Connect() to GainNode 24
125.855057: AudioBufferSourceNode 78 Start(0.000000, 0, 2.22507e-308)

Click Back:
136.867120: gain for 44 SetValue value=1 time=0.000000 constant=0
136.867120: gain for 44 SetValue value=0.695 time=0.000000 constant=0
136.983220: gain for 44 SetValue value=0.29 time=0.000000 constant=0
137.093515: gain for 44 SetValue value=0 time=0.000000 constant=0
137.093515: AudioBufferSourceNode 76 Stop(0.000000)
137.093515: gain for 44 SetValue value=1 time=0.000000 constant=0

Gecko is more faithfully reproducing the jumps in the audio signal that the client is requesting.

The Audio WG concluded that smoothing of AudioParams could not be done in a
way that worked in all situations, and so it was better that the value setters
did not attempt to do this [1].  The API provides automation methods to make the smooth transitions wanted here.  However, there may be some bugs in these automation methods [2].

[1] https://github.com/WebAudio/web-audio-api/issues/76#issuecomment-107679878
[2] https://github.com/WebAudio/web-audio-api/issues/652#issuecomment-158233760

Comment 4

[Karl Tomlinson (:karlt)]

Let's make this the evangelism bug and any automation method bugs can be tracked in the Web Audio component.

Comment 5

[Maire Reavy [:mreavy]]

Thanks, Karl!

Martin -- Can you or Andre help communicate this info back to the maker of this game?

Comment 6

[Martin Best (:mbest)]

So you want me to tell them that cracking in their audio, which only happens in our browser, is their fault because our spec is somehow more accurate?

I'm not sure I'm comfortable with that stance.  Need someone to walk me through this.

Comment 7

[Paul Adenot (:padenot)]

(In reply to Martin Best (:mbest) from comment #6)
> So you want me to tell them that cracking in their audio, which only happens
> in our browser, is their fault because our spec is somehow more accurate?
>
> I'm not sure I'm comfortable with that stance.  Need someone to walk me
> through this.

Initially, there was this thing called "de-zippering" in the spec, where parameters (here the volume) would be automatically smoothed when set. This was the cause of a number of problems, so it got removed from the specification. Chrome has not yet removed de-zippering from their implementation, but will (and this game will have the same glitch). We have never implemented de-zippering, because we always thought it was a bad idea, and preferred working at a spec level to remove it.

We've looked at what the game is doing here, and it's not doing volume changes the recommended way (and, as said above, will sound bad in Chrome, WebKit and IE once they remove de-zippering). The developers should use the automation methods [0] instead, which purpose is exactly to change parameter smoothly. Specifically, the developers could use code like this to achieve a ramp from 1.0 (full-volume) to 0.0 (silence), lasting 1.0 seconds, starting at the current AudioContext time:

    gain.gain.setValueAtTime(1.0 /* initial value */,
                             audiocontext.currentTime /* start time for the ramp */);
    gain.gain.linearRampToValueAtTime(0.0 /* final value */,
                                      audiocontext.currentTime + 1.0 /* end time for the ramp */); 

(I'll note that other curve shapes are available, see [0]).

This is:
- faster (as in, more optimized)
- better (the ramp will be more smooth)
- more resilient against main-thread load issues
- spec compliant
- works _now_ in all browser without glitches

Please let me know if they need to have a chat with us to have further clarifications, happy to help. 

[0]: http://webaudio.github.io/web-audio-api/#AudioParam

Comment 8

[Martin Best (:mbest)]

Ok great, that is very helpful and makes a lot more sense.

Comment 9

[Martin Best (:mbest)]

Andre, do you have any direct contacts at RSI?

Comment 10

[Martin Best (:mbest)]

Do you have any contacts at RSI?

Comment 11

[Andre Vrignaud [:andre] [Seattle - PST]]

Chasing down COO/VP Biz Dev contact through Mark Deloura, more soon hopefully. No direct contacts, but this has good chance of getting us in.

Comment 12

[Andre Vrignaud [:andre] [Seattle - PST]]

Received contact information, have reached out. He's in UK, so may be a delay, but I think we're likely to get a response. Who on this thread should be connected to the RSI engineers when we connect?

Comment 13

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

(In reply to Martin Best (:mbest) from comment #10)
> Do you have any contacts at RSI?

I do not. But it seems like Andre has it under control.

Comment 14

[Andre Vrignaud [:andre] [Seattle - PST]]

Have connected with both the VP Biz Dev and Publishing of Cloud Imperium Games (developers of Star Citizen), as well as with their external web agency Turbulent, who developed both the Star Citizen crowd-funding websites/resources as well as star map.

I will share recommended fix and update status.

Comment 15

[Adam Stevenson [:adamopenweb]]

I tested this today and didn't get any cracking sounds. Can someone confirm if this is fixed now?

Comment 16

[Paul Adenot (:padenot)]

Maybe they fixed it yeah.

Comment 17

[Mike Taylor [:miketaylr]]

Totally crack-free here.