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

Description Ahmad Saleem 2023-01-07 14:12:12 PST

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!

Comment 1 Radar WebKit Bug Importer 2023-01-14 14:13:16 PST

<rdar://problem/104265673>

Comment 2 Ahmad Saleem 2023-02-04 09:26:36 PST

PR - https://github.com/WebKit/WebKit/pull/9643

Comment 3 Ahmad Saleem 2023-02-05 15:27:14 PST

(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.