The main thread in the WebContent process is often busy with layout and
running JavaScript. This can cause audio to sound jittery and crack. To
avoid this behavior, we now drive audio on a secondary thread.
Note: Browser on Serenity uses AudioServer, the connection for which is
already handled on a secondary thread within LibAudio. So this only
applies to Lagom.
Rather than using LibThreading, our hands are tied to QThread for now.
Internally, the Qt media objects use a QTimer, which is forbidden from
running on a thread that is not a QThread (the debug console is spammed
with messages pointing this out). Ideally, in the future AudioServer
will be able to run for non-Serenity platforms, and most of this can be
aligned with the Serenity implementation.
The audio element behaves a bit differently than the video element in
that the audio element drives itself on a timer (as opposed to LibVideo
notifying the video element when a frame is available). So if an audio
element is paused while seeking, we wouldn't receive an updated playback
position until the element is unpaused.
This fixes an issue where you would have to click the play button twice
to re-start an audio track after it reached the end.
