Re: QEMU VNC Audio Patch

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

On Monday 12 December 2011 09:35:11 Daniel P. Berrange wrote:
> On Mon, Dec 12, 2011 at 02:27:51PM +0100, Gerd Hoffmann wrote:
> >   Hi,
> >
> > > 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.
> >
> > Wow.  I guess you run vnc client and qemu-kvm on the same machine?  Does
> > it still work that great if the data stream has to travel over the
> > network?
> >
> > One fundamental issue the vnc audio extension has is that both audio and
> > video travel over the same tcp pipe.  So a bulky screen update can
> > easily disturb audio playback by delaying the audio stream.  With slower
> > network it will be more noticeable of course.
> 
> Yeah, I'm not really expecting this VNC audio support to be a serious
> alternative to SPICE with audio. It was still nice to have the audio
> support in GTK-VNC though
> 
> Daniel
> 

   I actually run 3 or 4 VM's on the same machine as the viewer.

   I do not think that the VNC protocol is significantly different than the MP4 
protocol.   Both can interlace audio/video data.   And both can provide a 
quality experience.   In my opinion, it is really up to the *encoder* to 
ensure that the audio/video is multiplexed appropriately in the stream so that 
the client can properly decode things.   VNC protocol has the added benefit 
that the server can detect how powerful the client/network is via measuring 
the latency of updates.   It is my opinion that if the MPEG protocol can do 
it, so can the VNC protocol.

   Alternatively, the gtk-vnc client *could* make a second VNC connection to 
the same server, log-in, negotiate audio encodings, and not perform framebuffer 
requests.  Just listen for audio  (or request 1 pixel updates or something 
like that).   A dual connection approach that is also compatible with a single 
connection approach.

Just my thoughts,
~Steven