[Webkit-unassigned] [Bug 241223] Web audio rendering becomes garbled with switching from speakers to headphones (and vice-versa)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=241223

--- Comment #7 from Chris Dumez <cdumez at apple.com> ---
(In reply to Chris Dumez from comment #6)
> (In reply to Chris Dumez from comment #5)
> > (In reply to Chris Dumez from comment #4)
> > > One thing I noticed is that RemoteAudioDestination::render() normally gets
> > > called with numberOfFrames=128. However, when I plug in the headphones,
> > > RemoteAudioDestination::render() then gets called consistently with
> > > numberOfFrames=480.
> > 
> > And when I restart the browser with the headphone plugged in, numberOfFrames
> > becomes 128 again. As far as I know, our code assumes a rendering quantum of
> > 128 for WebAudio so it is probably not too surprising that rendering goes
> > bad when the rendering quantum becomes 480.
> > 
> > As far as I know MediaSessionManagerCocoa::updateSessionState() is supposed
> > to set the preferred buffer size of 128 when Web Audio is in use. However,
> > clearly this gets ignored when switching audio output.
> 
> Ok, so interestingly,  MediaSessionManagerCocoa::updateSessionState() does
> get called when I plug in my headphones and does call
> `AudioSession::sharedSession().setPreferredBufferSize(128)`. However,
> `AudioSessionMac::setPreferredBufferSize()` early returns because
> `m_bufferSize == bufferSize`.
> 
> If I comment out the early return when `m_bufferSize == bufferSize`, then
> the audio stays good when plugging in the headphones.

Normally, you'd expect AudioSessionMac::handleBufferSizeChange() to get called here and update m_bufferSize since the buffer size did change. However, we set the listener in AudioSessionMac::addBufferSizeObserverIfNeeded(), we pass in the defaultDevice(). However, the default device is changing when we connect the headphones. As a result, our observer becomes useless.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221114/65c3f749/attachment.htm>