Closed Bug 1226481 Opened 9 years ago Closed 8 years ago

Audio Cracking in Star Citizen Map

Categories

(Web Compatibility :: Desktop, defect, P1)

x86
Windows 10
defect

Tracking

(firefox42 affected, firefox43 affected, firefox44 affected, firefox45 affected)

RESOLVED FIXED
Tracking Status
firefox42 --- affected
firefox43 --- affected
firefox44 --- affected
firefox45 --- affected

People

(Reporter: mbest, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Whiteboard: [sitewait])

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.
Blocks: gecko-games
It might be because we don't implement de-zippering, I'm investigating.
Assignee: nobody → padenot
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!
Rank: 7
Priority: -- → P1
(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
Depends on: 1227411
Let's make this the evangelism bug and any automation method bugs can be tracked in the Web Audio component.
Assignee: padenot → nobody
Component: Web Audio → Desktop
Product: Core → Tech Evangelism
Version: 45 Branch → unspecified
Thanks, Karl! Martin -- Can you or Andre help communicate this info back to the maker of this game?
Flags: needinfo?(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.
Flags: needinfo?(mbest)
(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
Flags: needinfo?(mbest)
Ok great, that is very helpful and makes a lot more sense.
Flags: needinfo?(mbest)
Andre, do you have any direct contacts at RSI?
Flags: needinfo?(avrignaud)
Do you have any contacts at RSI?
Flags: needinfo?(dchinniah)
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.
Flags: needinfo?(avrignaud)
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?
(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.
Flags: needinfo?(dchinniah)
Depends on: 1228207
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.
I tested this today and didn't get any cracking sounds. Can someone confirm if this is fixed now?
Whiteboard: [sitewait]
Maybe they fixed it yeah.
Totally crack-free here.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.