From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cb7PM-0000F7-6G for qemu-devel@nongnu.org; Sun, 05 Dec 2004 20:11:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cb7PL-0000Ei-Dp for qemu-devel@nongnu.org; Sun, 05 Dec 2004 20:11:19 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cb7PL-0000Ef-7H for qemu-devel@nongnu.org; Sun, 05 Dec 2004 20:11:19 -0500 Received: from [131.111.8.133] (helo=ppsw-3.csi.cam.ac.uk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cb7FY-00088b-02 for qemu-devel@nongnu.org; Sun, 05 Dec 2004 20:01:12 -0500 Received: from rn214.trin.cam.ac.uk ([131.111.193.203]:44429) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp id 1Cb7FQ-0003Tv-C5 (Exim 4.44) for qemu-devel@nongnu.org (return-path ); Mon, 06 Dec 2004 01:01:04 +0000 Message-ID: <41B3AF50.9000603@hermes.cam.ac.uk> Date: Mon, 06 Dec 2004 01:01:04 +0000 From: Richard Neill MIME-Version: 1.0 Subject: Re: [Qemu-devel] Soundwrapper and artsd (fails to share) References: <41B3A197.2030807@hermes.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 malc wrote: > On Mon, 6 Dec 2004, Richard Neill wrote: > >> Dear All, >> >> I wonder why the following doesn't seem to work? Qemu still takes an >> exclusive lock on the soundcard, even when invoked with soundwrapper. >> I'm using this invocation: > > > There is no such thing as excluse soundcard lock, /dev/dsp is being opened > and if sound hardware does not support multiple hardware channels then > this is where the story ends. Sorry - please excuse my poor terminology. What I mean is that when qemu is running, no other application may play sounds. > >> >> soundwrapper /usr/local/bin/qemu -cdrom servicepacks.iso -hda >> winxp_pro_hd.img -boot c -localtime -enable-audio -m 256 -monitor stdio > > > I'm not quite sure what soundwrapper is, but if it is just a script that > calls artsdsp under the hood, then it's a no go: As I understand it, soundwrapper intercepts the open() call to /dev/dsp, and redirects it to a socket, talking to artsd. > > > # artsdsp i386-softmmu/qemu > artsdsp works only for binaries > Sorry, I'm afraid I don't understand this. qemu is a binary, isn't it? 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 ] > >> >> No other audio can be played on the host while qemu is running. Does >> anyone have any ideas? Thanks for your help, >> > > Perhaps some dmix(ALSA's) magic can work, but you'll have to RTFM about it > yourself. Thanks for the idea - I shall try it. Regards Richard