From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cb7kd-00063B-Bg for qemu-devel@nongnu.org; Sun, 05 Dec 2004 20:33:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cb7kc-00062e-SA for qemu-devel@nongnu.org; Sun, 05 Dec 2004 20:33:19 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cb7kc-00062T-OL for qemu-devel@nongnu.org; Sun, 05 Dec 2004 20:33:18 -0500 Received: from [38.113.3.61] (helo=smtp-out.hotpop.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cb7ac-0003GH-KT for qemu-devel@nongnu.org; Sun, 05 Dec 2004 20:22:58 -0500 Received: from phreaker.net (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id 8F628AA0859 for ; Mon, 6 Dec 2004 01:22:55 +0000 (UTC) Received: from jbrown.mylinuxbox.org (pcp03144805pcs.midval01.tn.comcast.net [68.59.228.236]) by smtp-1.hotpop.com (Postfix) with ESMTP id 008DF1A009A for ; Mon, 6 Dec 2004 01:22:54 +0000 (UTC) Date: Sun, 5 Dec 2004 20:21:47 -0500 From: "Jim C. Brown" Subject: Re: [Qemu-devel] Soundwrapper and artsd (fails to share) Message-ID: <20041206012147.GA16088@jbrown.mylinuxbox.org> References: <41B3A197.2030807@hermes.cam.ac.uk> <41B3AF50.9000603@hermes.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B3AF50.9000603@hermes.cam.ac.uk> 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 On Mon, Dec 06, 2004 at 01:01:04AM +0000, Richard Neill wrote: > I did the following tests. In all cases, commands (i) and (ii) are run > simultaneously in different terminals: > > 1) > (i) play file1.wav > (ii) play file2.wav > Result: > file1.wav plays. When it is finished, file2.wav plays. > > > 2) > (i) soundwrapper play file1.wav > (ii) soundwrapper play file2.wav > Result: > file1.wav and file2.wav play simultaneously. > > > 3) (i) soundwrapper qemu [qemu options] > (ii) soundwrapper play file2.wav > > Result: qemu's audio is played. file2.wav does not start playing until > qemu has shut down. In my view, this behaviour is undesirable; it's also > rather puzzling. After all, to the O.S., qemu is just another > application, isn't it? So, if soundwrapper can redirect the output of > play (i.e. the sox binary), why can't it do the same with qemu. > > [Info: Host = Linux/KDE/ARTS; guest = WinXP ] > This is because qemu accesses the soundcard on a level that artsdsp doesn't support ... this means that qemu ends up accessing the soundcard directly, which causes it to by-pass arts completely. (Last I checked, it was because qemu uses fopen() instead of open().) You probably have artsd releasing the souncard when it is not in use, otherwise qemu would just hang forever while waiting for the soundcard to be released by arts. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.