Re: QEMU VNC Audio Patch

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

On Friday 09 December 2011 04:10:49 you wrote:
> On Fri, Dec 02, 2011 at 12:16:22AM -0500, Steven Carr wrote:
> > Is there a reason you want the audio as a separate GObject instead of
> > simply adding 3 new emitters on the existing GObject?   I am new to the
> > gnome development methodology and do not understand the benefit of having
> > the audio broken out as a separate GObject.
> 
> It makes life slightly easier when you have higher level APIs that
> are wrapping VncConnection. eg, you don't need to keep chaining
> together the start/stop/data  signals across all your API layers.
> You can just pass in the audio object. Also it makes it easier to
> provide & use implementations, eg we could provide a simple pulse
> audio impl that can be used with 1 api call, instead of requiring
> the app code to connect to multiple signals & implement handlers.
> 
> > Attached is a diff that extends gtk-vnc's existing GObject to add the
> > three new QEMU Audio messages (Begin, End, and Data).   3 new functions
> > (both display and connection) are added to support (Enable, Disable, and
> > SetFormat).   Since the format for the audio is only 3 parameters, I
> > simply made them a part of the function call instead of a separate
> > structure for them.  I think it makes the code easier to read.   The
> > names were chosen to align with the QEMU code that describes the messages
> > (Begin/End/Data).
> >
> > Also, Pulse Audio output support is added to the example gvncviewer
> > application and has been tested against qemu-kvm on RHEL 6.1 x86-64.
> >
> > Comments are welcomed,
> 
> Thanks for the updated patch. I am going to commit this, but then
> apply some more change ontop of it, to imlement some of the concepts
> I've described earlier.

Works for me.   Just trying to give back to the OS community-at-large.

> 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.


> 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?)

   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.

> 
> Regards,
> Daniel
> 

I am glad I could provide a patch that you can build off of,
~Steven Carr