Re: [Qemu-devel] [RfC PATCH 11/11] spice: add audio

[Gerd Hoffmann <kraxel@redhat.com>]

   Hi,

>> c. I have a really hard time following what rt clock (regardless
>> of monotonicity is doing here at all)
>
> Accept audio data with the correct rate. When sending directly to the
> audio device the host hardware controls this. Spice sends the audio data
> off to the network, so this doesn't work. The math used by spice here
> looks like a old version of the noaudio code for rate control (/me
> inherited that code so I don't know for sure), which makes sense to me.

malc pointed out in irc simliar discussions came up for esd support.
Thread starts here:
   http://www.mail-archive.com/qemu-devel@nongnu.org/msg06593.html

Summary: having two clocks should better be avoided (one being vmclock 
and the other esd consuming the data, i.e. indirectly the sound hardware 
actually playing the data).  So instead of using vmtime for rate control 
the esd driver just feeds esd as fast as it can accept data.

Advantage of that approach:

   You'll avoid all clock sync issues such as audible audio blibs
   happening in case one clock is slightly faster as the other.

Problems with that approach:

   General: It adds extra latency.

   Spice: A client may or may not be connected.  In case no client is
   connected nobody consumes the sound stream data and thus there is no
   clock ...

cheers,
   Gerd