On Thu, Jun 9, 2016 at 10:55 AM, Alex Williamson <alex.l.william...@gmail.com> wrote: > This seems rather obvious doesn't it? An emulated audio device is just a > blob of code that requires the CPU to run it. Generating audio, it's highly > susceptible to latency issues. At the same time you're apparently playing a > game that consumes significant CPU time. Total CPU cycles on the system > have a fixed limit. Therefore any time you exceed that limit or get close > enough for scheduling latency to become an issue, you can expect the audio > emulation to suffer. This is why bare metal has devices dedicated to > various activities. Solutions are 1) get a faster system, 2) load the > system less or maybe more optimally, 3) assign a device to offload the work. > > The "more optimally" part of 2) might include pinning vCPUs, pinning the > emulator thread, leaving sufficient CPU power unassigned so that the host > has enough capacity to run emulation at full speed, reducing host overhead > via things like hugepages, etc...
I don't need to be playing games for it to have problems. I shut down everything in both the host and guest, plenty of cycles to spare. If I were to test the speaker setting in the windows Control Panel I get crackling. I have an i7 4790 so I thought I had enough cycles to be able to handle that part on its own. I do have vCPUs pinned to 2 of the cores, leaving 2 cores for the host. I also have hugepages setup. I tried changing the governor to performance and pinning qemu to non-VM cores. It seems I cannot get a setup that doesn't have audio issues. I was wondering if there was a better way to move audio from the guest to the host. _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
