From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GJEIL-00064z-OH for qemu-devel@nongnu.org; Fri, 01 Sep 2006 15:03:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GJEIJ-00063k-Ki for qemu-devel@nongnu.org; Fri, 01 Sep 2006 15:03:12 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJEIJ-00063W-FC for qemu-devel@nongnu.org; Fri, 01 Sep 2006 15:03:11 -0400 Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GJESD-0003Vq-9U for qemu-devel@nongnu.org; Fri, 01 Sep 2006 15:13:25 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GJEI0-0004Y8-O1 for qemu-devel@nongnu.org; Fri, 01 Sep 2006 21:02:53 +0200 Received: from n100h003.catv.ext.ru ([n100h003.catv.ext.ru]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Sep 2006 21:02:52 +0200 Received: from malc by n100h003.catv.ext.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Sep 2006 21:02:52 +0200 From: malc Date: Fri, 1 Sep 2006 19:02:26 +0000 (UTC) Message-ID: References: <20060830104549.fe233e29.cylix@solace.info> <44F71A14.6070509@win4lin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: news Subject: [Qemu-devel] Re: esd audio output patch and debuging. Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Leonardo E. Reiter win4lin.com> writes: > > malc, > > Other than the lack of error handling and blocking mode, what is the > problem with using QEMU's VM clock as the audio clock source? In my > experience from older projects using esd (not related to QEMU), it is > almost impossible to get reliable timing from ESD, especially if you are > transporting over a network. The timing will certainly not be accurate > enough for example for Windows guests using Windows Media Player, etc. > Plus, you have to factor in socket buffering and underruns due to > network latency if you expect anything synchronous on the socket. So > what is the reason for objecting to the QEMU vm clock, much like the > mute audio driver uses? I just want to know your reasoning for it just > to further my own understanding. Mute/wav rendering works by the virtue of having one clock source, i.e. vm clock, furthermore the writes are non-blocking and instantaneous[1]. With esd one has to deal with two clock sources - one is vm clock other is esds ability to consume the data. If vm clock is a bit lower w.r.t. the audio clock esd uses - you will always starve the esd and in turn audio subsystem it uses. All in all real-time(in a loose sense) audio will only work if your only constraint is the receivers ability to consume data. Given esds interface the only safe way to do that is by emulating of a blocking write, this in trun (given all other things into consideration) means threads and interaction with QEMUs audio/main loop a'la sdlaudio or coreaudio. [1] Less so for wav due to I/O, but close enough for all intents and purposes.