Bug 250279
| Summary: | Use correct HRTF elevation response for negative elevations | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ahmad Saleem <ahmad.saleem792> |
| Component: | Web Audio | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | cdumez, jer.noble, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Ahmad Saleem
Hi Team,
While going through Blink's commit, I came across following commit, where it seems to be an issue to due to handling of negative elevation.
Test Case (from Chrome Bug) - http://vm-1015-user.virt.ch.bbc.co.uk/binaural/panner_test/
STEPS TO REPRODUCE (Copied from Chrome Bug - https://bugs.chromium.org/p/chromium/issues/detail?id=412442):
1. Go to - http://vm-1015-user.virt.ch.bbc.co.uk/binaural/panner_test/
2. Click "Play" and move the elevation slider.
3. Listen over headphones.
What is the expected behavior?
Elevation > 0, moves the sound higher, above your head. Elevation < 0 moves the sound lower, below your head.
What went wrong?
When elevation goes below -29, the sound jumps to the top.
_________________
Blink Commit: https://src.chromium.org/viewvc/blink?view=revision&revision=181986
WebKit Source - https://github.com/WebKit/WebKit/blob/1105db4ef4beff2c87fbe05387c58123ee89ff97/Source/WebCore/platform/audio/HRTFElevation.cpp#L151
_______
I am not sure whether we have anything special that we don't get impacted by this but since we have same code, just wanted to raise this and ask someone with headphones to see if this is reproducible. I have USB-A headphones from work (don't work on MacBook Pro). :-(
Just wanted to raise to get input.
Thanks!
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/104265673>
Ahmad Saleem
PR - https://github.com/WebKit/WebKit/pull/9643
Ahmad Saleem
(In reply to Ahmad Saleem from comment #2)
> PR - https://github.com/WebKit/WebKit/pull/9643
Based on discussion with Chris on PR, it needs to have automated test case and local testing will not be sufficient / sustainable long term. Unfortunately, I am not sure on how to write the test case, so I closed my PR. Thanks!
NOTE - Upon local build, I confirmed that it does fix the issue and match Chrome Canary 112 on the test case mentioned in Comment 0, where if it goes below -29, there is a shift.
Ahmad Saleem
https://github.com/chromium/chromium/commit/5c31073f086be3f8c226c01d7954ea8f4d7eddaf