From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O2jUH-0002D9-B3 for qemu-devel@nongnu.org; Fri, 16 Apr 2010 07:13:29 -0400 Received: from [140.186.70.92] (port=34359 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2jUF-0002CI-RU for qemu-devel@nongnu.org; Fri, 16 Apr 2010 07:13:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O2jUE-0006U7-1r for qemu-devel@nongnu.org; Fri, 16 Apr 2010 07:13:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52227) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2jUD-0006Tt-OZ for qemu-devel@nongnu.org; Fri, 16 Apr 2010 07:13:25 -0400 Message-ID: <4BC84645.5040007@redhat.com> Date: Fri, 16 Apr 2010 13:13:09 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RfC PATCH 11/11] spice: add audio References: <1271238922-10008-1-git-send-email-kraxel@redhat.com> <1271238922-10008-12-git-send-email-kraxel@redhat.com> <4BC8228D.10909@redhat.com> In-Reply-To: <4BC8228D.10909@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org 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