performance: 0.891
device: 0.882
graphic: 0.863
files: 0.841
socket: 0.689
boot: 0.627
semantic: 0.598
permissions: 0.536
network: 0.534
other: 0.530
PID: 0.493
vnc: 0.476
debug: 0.260
KVM: 0.139

AC97+DirectSound only polls for audio every 10ms with no way to change it
Description of problem:
The AC97 device emulation, at least in combination with the DirectSound backend, only polls for audio every 10ms, meaning that DMA interrupts are received at a maximum frequency of 100Hz. This applies regardless of how large the buffers in the AC97's buffer list are, meaning that if one buffer takes less than 10ms to play, glitches can be heard with no possible mitigations on the host system.

I came across this when fiddling with Serenity's own latencies in the AC97 driver and userland mixer. As soon as less than 512-sample buffers are used, audio becomes glitchy. Based on timing tests, kernel and userland processing of audio combined takes less than 200μs for one buffer, while the lowest average rate that DMA interrupts are received at is almost exactly 10ms.

No changes to the dsound latency option, as listed [here](https://www.qemu.org/docs/master/system/invocation.html?highlight=dsound), made any difference; I tried as low as 2ms: `-audiodev dsound,id=snd0,latency=2000`. As far as I can tell there are no IRQ- or latency-related options for the AC97 emulation.
Steps to reproduce:
1. Use SerenityOS as of the above commit.
2. Before building, include an audio file in Base/home/anon; most ordinary FLAC, WAV and MP3 files created without options with ffmpeg should work.
3. Boot Serenity in QEMU on Windows without any special run configuration.
4. Play the audio file with `aplay <filename>`, hear glitches.