qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [RfC PATCH 11/11] spice: add audio
Date: Fri, 16 Apr 2010 13:13:09 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4


  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/address@hidden/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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]