Re: QEMU VNC Audio Patch

[Steven Carr <Steven Carr scaa-usa com>]

On Friday 09 December 2011 10:41:55 you wrote:
> On Fri, Dec 09, 2011 at 10:30:28AM -0500, Steven Carr wrote:
> > On Friday 09 December 2011 04:10:49 you wrote:
> > > What has been your experiance with the overall quality / performance
> > > of the audio coming out of VNC ?
> >
> > I started using a modified TightVNC Java Client from
> > http://www.paulsd.com/2009/VNC/   The client kept crashing and had
> > significant audio glitches.   And on top of things, it was a bit awkward
> > to use.   I hacked pulseaudio into the src.rpm for the SL61 gtk-vnc
> > library so that I could add audio output to the virt-manager without
> > having to touch that code as well (KISS principle).   Using this modified
> > rpm, I am able to watch youtube videos, full screen in the VM (1600x1200)
> > and have occasional audio issues. Maybe 1 detectable hiccup a minute.
> >
> > Now, my host is a 12-core i7 3.3GHz (6681 BogoMips) on a P6T6 WS
> > Revolution Motherboard with 24GB of ram, running Scientific Linux 6.1
> > x86-64.   The audio device is an 82801JI HD Audio Controller.   The video
> > device is a six output AMD Radeon 6900 Series using fglrx drivers.   It
> > is a pretty beefy system and I would not consider it typical.
> >
> > The Guest OS is WinXP in a QEMU/KVM Virtual Machine (the default VM
> > system on SL61), setup to use the emulated AC97 audio device model (I am
> > not sure if AC97 is a better virtual device).   In the WinXP system,
> > MicroSoft has graciously provided Beethoven's Symphony No. 9 for me to
> > test against.   I play that with Windows Media Player.   qemu-kvm uses
> > 22% of one of my cores and pulseaudio uses 2.6%.   No detectable audio
> > skipping or jumping unless I am running the windows media player at full
> > screen on one of my six displays and displaying some sort of
> > visualization.   I was able to watch non-full screen youtube videos with
> > the occasional audio drop out.
> 
> Ok, that is very interesting / useful. I was testing with a Fedora 14
> guest, and I hears glitches every couple of seconds, particularly if
> any other data is arriving on the vnc socket eg due to screen refresh.
> 
> It would not surprise me if there was a significant difference in
> behaviour between Windows & Fedora for sound output. So I should
> probably try out a WIndows guest too and see how things go.
> 
> > > I've tested by playing a FLAC file in the guest, and the audio is
> > > slightly crackly. In addition the CPU usage of gvncviewer and
> > > pulseaudio on the host is absurdly high - ~40-40%. By comparison,
> > > rhymbox playing the same FLAC file in the host, consumes ~0% CPU
> > > and causes ~0% cpu usage from pulseaudio. I've no looked into what's
> > > going on here & suspect it might be just an artifact of the small
> > > buffers QEMU sends, but wondered if you experianced any similar
> > > behaviour in your testing ?
> >
> >    The previous patch was better in the skipping aspect, where the audio
> > data was dispatched to pulseaudio directly from the event loop, and not
> > redirected back via the GObject interface.   I am not entirely sure, why.
> >   When I slapped in some logging I would see batches of messages come in,
> > then batches being sent to pulse audio.   Are the Audio messages being
> > batched and then processed in some sort of idle loop?  (co-routines?)
> 
> That's a useful  data point. The co-routine will basically consume as
> much data as possible from the VNC source before returning to the main
> loop - eg until it gets EAGAIN on the file descriptor. If there are
> large framebuffer updates coming in, this could be introducing significant
> delays between receiving the audio & sending it onto pulseaudio. So it is
> possible that we should artifically return to the main loop, even if we
> have not got EAGAIN, just to make sure we don't delay audio.
> 
> I also noticed that the Fedora guest at least was sending audio in very
> small packets - as little as 1 sample in size, but at most 10 samples.
> This is what was causing the crazy CPU usage. I tried altering the code
> so that it receives 100ms of audio before sending it onto pulseaudio,
> and that dropped the CPU usage to acceptable levels. I need to investigate
> the audio glitching though, before I commit that.
>

I'm betting that your guest OS is not using DMA for audio output.   If I were 
writing the virtual driver in QEMU, I would be passing the packet data from 
the virtual driver to the VNC connection as I received the data.   Which would 
lead me to think that your receiving a trickle of data because QEMU is 
receiving it from the guest OS in a trickle form.   Is your guest using SB16 
emulation?

I just put a printf() in the example viewer for audio output packet data and I 
am receiving an average audio packet data size of 740 bytes (roughly 185 
samples).
> >    In my case, I am not trying to play video games or watch movies in my
> > VM. I am really looking for 1/3 second audio alerts from pidgin so I
> > don't have to keep checking to see if any of my co-workers has sent me a
> > message.   But I can see people trying to run some sort of full
> > audio/video multimedia application on a Pentium 3 and complaining about
> > it.
> 
> Yeah, even your minimal use case is a good step forward. If people want
> to watch full screen video inside a VM they really ought to just use
> SPICE isntead, since that does some very clever stuff to optimize video
> playback. Thanks for your  patches. I make ask you to test again once
> I've done some more coding to check it still works well for you.
> 
> Regards,
> Daniel
> 

Versions of the software I am using on the Host.   Just an FYI

[scarr@bumblebee examples]$ rpm -qa | grep qemu
qemu-kvm-0.12.1.2-2.160.el6_1.2.x86_64
gpxe-roms-qemu-0.9.7-6.7.el6.noarch
qemu-img-0.12.1.2-2.160.el6_1.2.x86_64

[scarr@bumblebee examples]$ rpm -qa | grep virt
python-virtinst-0.500.5-3.el6.noarch
libvirt-java-0.4.7-1.el6.noarch
libvirt-0.8.7-18.el6_1.1.x86_64
virt-manager-0.8.6-4.el6.noarch
libvirt-devel-0.8.7-18.el6_1.1.x86_64
virt-viewer-0.2.1-3.el6.x86_64
libvirt-python-0.8.7-18.el6_1.1.x86_64
virt-top-1.0.4-3.8.el6.x86_64
libvirt-java-devel-0.4.7-1.el6.noarch
libvirt-client-0.8.7-18.el6_1.1.x86_64

I would be happy to be a test subject for your changes,
~Steven Carr