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
