paul@ Thanks for the issue.

On navigating to the given link above, we can see 'Error 404 - Page not found' error. 
Request you to provide a URL which can be accessed and where this issue can be reproduced, which will help in further triaging of the issue.

Thanks..

Sorry seems I failed the copy/paste, here's the model hoping it will be tested before our bugfix ship in production
https://sketchfab.com/models/68c1cd74bb6d4015b9542ce0db2f247b

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 17.10 using chrome reported version #67.0.3396.99 and latest canary #69.0.3486.0.

Bisect Information:
=====================
Good build: 66.0.3341.0
Bad Build : 66.0.3342.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/45d52b4fa28ff0c9c840b7f25e109a7a502313aa..02938fe25079c7ed527dc2481fadb03e5ff732b0

From the above change log suspecting below change
Change-Id: Ic1da32c27f9e4f29e2df3bcbb6dd0bd485409e0e
Reviewed-on: https://chromium-review.googlesource.com/665318

rtoy@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

Thanks, krajshree, for doing the bisect.  As mentioned in  bug 764396 , this is a required change according to the spec.  We deprecated this in Oct 2017 with a console warning and finally made the change in Feb 2018. Also see https://www.chromestatus.com/features/5287995770929152. AFAIK, Firefox never implemented the panner smoothing so using the value setter was equivalent to calling setValueAtTime().

In addition, setPosition is supposed to be equivalent to calling setValueAtTime for each coordinate, so setPosition shouldn't change the glitches.  (If it does, then that's a bug in chrome.)

So instead of doing panner.positionX.value = x, you should do something like panner.positionX.setTargatAtTime(x, context.currentTime, timeConstant).  Set timeConstant to about 20 ms or so, depending on how fast or slow you want the transition to be.  However, I think only Chrome and Firefox have implemented automation methods for the panner postion.

Or maybe use panner.positionX.linearRampToValueAtTime(x, context.currentTime + eps) where eps is some small value probably around 16 ms or so.  This makes the panner transition smoothly between the previous position and the new position, except that the audio will be 16 ms or so behind the actual position. I'm assuming you're getting the position from the mouse drag.

> If it does, then that's a bug in chrome.

SetPosition/Orientation does fix it.

> Or maybe use panner.positionX.linearRampToValueAtTime
Thanks, we'll check it

Hmm. That's really weird that setPosition should fix it because the current code says setPosition calls setValueAtTime: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webaudio/panner_node.cc?rcl=2e1b2236f037610edad12ebad4d1ce20431b7db2&l=442

Similarly for setOrientation.

But these represent a different issue from this one.  If I can reproduce that, I'll file a new issue for setPosition/orientation.

Looking forward to seeing if setTargetAtTime or linearRampToValueAtTime fixes the glitches for you.

The NextAction date has arrived: 2018-07-23

We tried mutiple venues without success:
- we all get glitch on setValueAtTime
- some member of the team have SetTargetAtTime, SetPosition (seems to depend on headphones quality though)

The only one we don't seem to get any glitch is the linearRampToValueAtTime, but it reverts to old values when the linear Ramp time is done... 

Attached is the glitch we get on SetTargetAtTime, SetPosition 
(the one that not everyone reproduce here)

Deleted: scratch.wav 310 KB

scratch.wav 310 KB Download

Glitches from setValueAtTime is expected; you're suddenly moving the position which causes instantaneous changes in audio. setTargetAtTime might glitch, depending on the time constant used. I think the old code effectively had a time constant of about 50 ms. (But I can't remember for sure.)

linearRampToValueAtTime should result in the position being the value for linearRampToValueAtTime.  That's a bug if that's not true, but I've heard of any one else having issues with that.  Are you sure you didn't accidentally reset the location?

I hear a small glitch at the end of scratch.wav but that's probably because the sample ended.  Otherwise, I don't hear any glitch.

I was wrestling with the same problem until I found this issue. Setting panner.position{XYZ}.value glitches the audio on Chrome 68.0.3440.75, but is working fine on Firefox.


See https://vektor.space/q3webrtc_glitched.html for a version using panner.positionX.value, the fire audio sources generate quite a bit of scratches/static.

The fixed version (https://vektor.space/q3webrtc.html) uses the setPosition, setOrientation API.

The glitched version is using Emscripten's default OpenAL to WebAudio library (https://github.com/kripken/emscripten/blob/incoming/src/library_openal.js#L605)

paul@sketchfab.com: Can you comment on where the glitches are in scratch.wav?

slimkallas@gmail.com: I can't really hear the difference between the glitched and fixed version.  The background rumbling noise kind of hides things if you do't know what you're listening to.  In any case a smaller pure webaudio example would be great.

setPosition should be identical to panner.positionX.value, barring implementation bugs in Chrome.

I recorded both sounds at the same place, the only difference is that deprecated_api.mp3 uses setPosition/setOrientation and new_api.mp3 uses panner's position/orientation setters.

Deleted: deprecated_api.mp3 262 KB

deprecated_api.mp3 262 KB Download

Deleted: new_api.mp3 326 KB

new_api.mp3 326 KB Download

Thanks for the recordings. I hear the difference very clearly now.  Now I need to find a smaller repro case that shows the effect and that I can edit to test with....

So I attempted to create a repro case for this, only to find out both of the versions generate static.

See https://jsfiddle.net/0d5aL9ne/

I know this doesn't show the difference in this issue, but is this normal behaviour?

Thanks for the repro case. setPosition and the position value setter are supposed to be have the same: both should be as if you called positionX.setValueAtTime().  So if one causes glitches, the other should too.

It's not clear, but to hear the difference, I should set OLD_API to be true or false, depending on whether I want setPosition (true), or value setter (false)?

Yes, although in this case both produce a similar result.

The NextAction date has arrived: 2018-08-13