qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Soundwrapper and artsd (fails to share)


From: Richard Neill
Subject: Re: [Qemu-devel] Soundwrapper and artsd (fails to share)
Date: Mon, 06 Dec 2004 01:01:04 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514



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.


<quote>
# artsdsp i386-softmmu/qemu
artsdsp works only for binaries
</quote>

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]