|
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.htmlSummary: 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
[Prev in Thread] | Current Thread | [Next in Thread] |