On 09/10/2012 12:06 PM, Jan Kiszka wrote: >>> Known issue, likely unfixable in QEMU due to hard-coded constraints of >>> the driver Windows uses (too small playback buffers). >> >> Would using real-time priority for the guest improve things? >> >> Of course that can be dangerous if the guest decides to spin and has as >> many vcpus as you have cores. > > We need to decouple the data path of that device from the rest of QEMU > first. Just prioritizing likely doesn't help.
Depends on what the guest is doing, but likely you are right. Luckily we're already doing that. > And then the problem might > be getting sufficient reactivity from the QEMU-external audio data path > as well. Those already have realtime priority. Doesn't guarantee the path is short enough but it may work. -- error compiling committee.c: too many arguments to function
