Skip to content

PannerNode.rollOffFactor with "linear" distance model is not clamped to [0, 1] in main browser engines #2206

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
cdumez opened this issue Jun 23, 2020 · 1 comment
Closed

PannerNode.rollOffFactor with "linear" distance model is not clamped to [0, 1] in main browser engines #2206

cdumez opened this issue Jun 23, 2020 · 1 comment
Assignees
@rtoy
Labels
Needs Edits Decision has been made, the issue can be fixed. https://speced.github.io/spec-maintenance/about/

Comments

@cdumez
Copy link

cdumez commented Jun 23, 2020 •
edited
Loading

Describe the issue

PannerNode.rollOffFactor with "linear" distance model is not clamped to [0, 1] in main browser engines. The spec says it should be here:
https://www.w3.org/TR/webaudio/#dom-pannernode-rollofffactor

However, if you set it to 2, in Chrome / Firefox / WebKit, it will return 2 after, not 1. We noticed this when trying to implement the specification behavior in WebKit.
@cdumez cdumez added Needs Discussion The issue needs more discussion before it can be fixed. Untriaged labels Jun 23, 2020
@cdumez cdumez changed the title PannerNode.rollOffFactor with distance model is not clamped to [0, 1] in main browser engines PannerNode.rollOffFactor with "linear" distance model is not clamped to [0, 1] in main browser engines Jun 23, 2020
@padenot
Copy link
Member

padenot commented Jun 25, 2020

This was discussed in the AudioWG weekly call:

  • This is intended: you can set any value, and it's clamped as part of the processing, on the render thread. This allows setting a value and then changing the mode and the value set might lie outside the range in the first more but be in the range in the second mode.
  • Resolution: add a sentence that says explicitly that the clamping happens as part of the processing, and the attribute on the control thread side reflects the value set. This is in line with most APIs and, more importantly, with AudioParam clamping.

@padenot padenot added Needs Edits Decision has been made, the issue can be fixed. https://speced.github.io/spec-maintenance/about/ and removed Needs Discussion The issue needs more discussion before it can be fixed. Untriaged labels Jun 25, 2020
@rtoy rtoy self-assigned this Jul 14, 2020
rtoy added a commit to rtoy/web-audio-api that referenced this issue Jul 17, 2020
@rtoy
Fix WebAudio#2206: Describe clamping of rolloffFactor
e3d5a9a 
The clamping of the rolloffFactor happens during the processing for
the distance computation.  The attribute is not changed; it reflects
the value that was set.
@rtoy rtoy closed this as completed in 7f301c2 Jul 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rtoy rtoy

Labels
Needs Edits Decision has been made, the issue can be fixed. https://speced.github.io/spec-maintenance/about/
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@padenot @rtoy @cdumez