RESOLVED FIXED219873
[GPUProcess] Bump QoS to UserInteractive for real-time audio rendering thread
https://bugs.webkit.org/show_bug.cgi?id=219873
Summary [GPUProcess] Bump QoS to UserInteractive for real-time audio rendering thread
Chris Dumez
Reported 2020-12-14 14:12:57 PST
Bump QoS to UserInteractive for real-time audio rendering thread. We create our own thread on WebContent side when the GPU Process is enabled since the CoreAudio rendering thread lives in the GPU Process. To ensure the same quality of service, we need to make sure the thread we create gets very high QoS.
Attachments
Patch (14.57 KB, patch)
2020-12-14 14:29 PST, Chris Dumez
ews-feeder: commit-queue-
Patch (14.64 KB, patch)
2020-12-14 14:35 PST, Chris Dumez
no flags
Chris Dumez
Comment 1 2020-12-14 14:29:30 PST
Chris Dumez
Comment 2 2020-12-14 14:35:18 PST
Peng Liu
Comment 3 2020-12-14 14:38:14 PST
Comment on attachment 416196 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=416196&action=review > Source/WTF/ChangeLog:8 > + Add QOS parameter to the Thread construct (similarly to WorkQueue) so that the caller can Maybe priority is a better name for the parameter?
Chris Dumez
Comment 4 2020-12-14 14:41:17 PST
(In reply to Peng Liu from comment #3) > Comment on attachment 416196 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=416196&action=review > > > Source/WTF/ChangeLog:8 > > + Add QOS parameter to the Thread construct (similarly to WorkQueue) so that the caller can > > Maybe priority is a better name for the parameter? QoS (quality of service) is the naming on our platforms. The concept of process/thread priority also exists on our platforms but has a different meaning. As a result, I wouldn't want to conflate the 2. Also note that I am merely following the pattern in WorkQueue, not introducing a new concept in this patch.
Geoffrey Garen
Comment 5 2020-12-14 15:17:33 PST
Comment on attachment 416196 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=416196&action=review > Source/WebCore/Modules/webaudio/AudioWorkletThread.cpp:69 > + }, ThreadType::Audio, m_parameters.isAudioContextRealTime ? Thread::QOS::UserInteractive : Thread::QOS::Default); What's the non-realtime case for audio? > Source/WebCore/worklets/WorkletParameters.h:40 > + bool isAudioContextRealTime; Where does this get initialized?
Chris Dumez
Comment 6 2020-12-14 15:23:25 PST
(In reply to Geoffrey Garen from comment #5) > Comment on attachment 416196 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=416196&action=review > > > Source/WebCore/Modules/webaudio/AudioWorkletThread.cpp:69 > > + }, ThreadType::Audio, m_parameters.isAudioContextRealTime ? Thread::QOS::UserInteractive : Thread::QOS::Default); > > What's the non-realtime case for audio? When you construct an OfflineAudioContext (instead of an AudioContext), audio is rendered offline into a buffer instead of in real time on the speakers. > > > Source/WebCore/worklets/WorkletParameters.h:40 > > + bool isAudioContextRealTime; > > Where does this get initialized? Yes, it is, based on whether or not the AudioContext is offline or not, which answers your question above.
Chris Dumez
Comment 7 2020-12-14 15:24:13 PST
Comment on attachment 416196 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=416196&action=review > Source/WebCore/Modules/webaudio/AudioWorkletMessagingProxy.cpp:57 > + worklet.audioContext() ? !worklet.audioContext()->isOfflineContext() : false For Geoff, this is where the isAudioContextRealTime flag gets initialized.
Geoffrey Garen
Comment 8 2020-12-14 15:40:24 PST
👍🏻
EWS
Comment 9 2020-12-14 15:44:58 PST
Committed r270806: <https://trac.webkit.org/changeset/270806> All reviewed patches have been landed. Closing bug and clearing flags on attachment 416196 [details].
Radar WebKit Bug Importer
Comment 10 2020-12-14 15:46:11 PST
Note You need to log in before you can comment on or make changes to this bug.