[Top][All Lists]
[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