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

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

[Richard Neill]

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:

soundwrapper /usr/local/bin/qemu -cdrom servicepacks.iso -hda 
winxp_pro_hd.img -boot c -localtime -enable-audio -m 256 -monitor stdio

No other audio can be played on the host while qemu is running. Does 
anyone have any ideas? Thanks for your help,

Regards

Richard



-- 
rn214@hermes.cam.ac.uk  **  http://www.richardneill.org
Richard Neill, Trinity College, Cambridge, CB21TQ, U.K.

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

[malc]

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.

>
> 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:

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

>
> 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.

Sincerely,
malc

-- 
mailto:malc@pulsesoft.com

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

[Richard Neill]

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

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

[Jim C. Brown]

On Mon, Dec 06, 2004 at 03:42:59AM +0300, 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.

Not at all. One can pipe the sound thru daemons such as Artsd, ESD, etc.
These daemons then muliplex the sound to the actual hardware. Of course
the programs have to be specially designed to use these daemons, but sometimes
you can use tricks to fool regular programs into thinking that they're talking
to the hardware when they are only sending messages to a pipe or socket. These
typically involve a wrapper of some sort.

Currently the wrappers don't work w/ qemu. (I've only tried 2, artsdsp and
esddsp). It isn't hard to add arts support to qemu, I just haven't had the time
to convert the code yet.

> 
> >
> >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:
> 
> <quote>
> # artsdsp i386-softmmu/qemu
> artsdsp works only for binaries
> </quote>

I don't get this error. It doesn't even make sense, because A) artsdsp works
for scripts and B) qemu is a binary. artsdsp is merely a script that makes use
of the LD_PRELOAD trick, which wraps open(), write(), and a few other things
in order to intercept attempts to open /dev/dsp (and related audio devices)
and replace them with messages to artsd.

Of course, artsdsp doesn't work for qemu anyways, so it's a moot point.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Jim C. Brown]

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.

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

[malc]

On Sun, 5 Dec 2004, Jim C. Brown wrote:

> On Mon, Dec 06, 2004 at 03:42:59AM +0300, 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.
>
> Not at all. One can pipe the sound thru daemons such as Artsd, ESD, etc.
> These daemons then muliplex the sound to the actual hardware. Of course
> the programs have to be specially designed to use these daemons, but sometimes
> you can use tricks to fool regular programs into thinking that they're talking
> to the hardware when they are only sending messages to a pipe or socket. These
> typically involve a wrapper of some sort.

Not at all what? Yes, there are sound daemons, but this does not change
the fact that there is no such concept as exclusive sound card lock, it
all comes down to what hardware is there behind /dev/dsp.

>
> Currently the wrappers don't work w/ qemu. (I've only tried 2, artsdsp and
> esddsp). It isn't hard to add arts support to qemu, I just haven't had the time
> to convert the code yet.

Considering that arts is essentually dead - that might not be a the wisest
way to spend time (http://www.arts-project.org/doc/arts-maintenance.html)

>
>>
>>>
>>> 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:
>>
>> <quote>
>> # artsdsp i386-softmmu/qemu
>> artsdsp works only for binaries
>> </quote>
>
> I don't get this error. It doesn't even make sense, because A) artsdsp works
> for scripts and B) qemu is a binary. artsdsp is merely a script that makes use
> of the LD_PRELOAD trick, which wraps open(), write(), and a few other things
> in order to intercept attempts to open /dev/dsp (and related audio devices)
> and replace them with messages to artsd.

I installed arts for the sole purpose of trying artsdsp and see when/why
it fails, it fails with the message above. Go figure.

>
> Of course, artsdsp doesn't work for qemu anyways, so it's a moot point.

FMOD comes with esound output driver, QEMU can (optionally) use FMOD and
all its output drivers, latency will be horrible though.

QEMU_AUDIO_DRV=fmod QEMU_FMOD_DRV=esd qemu -enable-audio ...

-- 
mailto:malc@pulsesoft.com

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

[malc]

On Sun, 5 Dec 2004, Jim C. Brown wrote:

> On Mon, Dec 06, 2004 at 01:01:04AM +0000, Richard Neill wrote:
>
> 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().)

Wrong, /dev/dsp is open(2)ed

>
> 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.
>
>

-- 
mailto:malc@pulsesoft.com

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

[Jim C. Brown]

On Mon, Dec 06, 2004 at 04:32:41AM +0300, malc wrote:
> Wrong, /dev/dsp is open(2)ed
> 

My version of qemu still uses fopen() actually, but this is based off of
a rather old version of qemu, and without your sound patches.

So qemu on arts still fails, even with that change. Figures.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Jim C. Brown]

On Mon, Dec 06, 2004 at 04:27:21AM +0300, malc wrote:
> >>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.
> >
> >Not at all. One can pipe the sound thru daemons such as Artsd, ESD, etc.
> >These daemons then muliplex the sound to the actual hardware. Of course
> >the programs have to be specially designed to use these daemons, but 
> >sometimes
> >you can use tricks to fool regular programs into thinking that they're 
> >talking
> >to the hardware when they are only sending messages to a pipe or socket. 
> >These
> >typically involve a wrapper of some sort.
> 
> Not at all what? Yes, there are sound daemons, but this does not change
> the fact that there is no such concept as exclusive sound card lock, it
> all comes down to what hardware is there behind /dev/dsp.

I was simply saying that the story doesn't end with the limitations of the hardware.

> >Of course, artsdsp doesn't work for qemu anyways, so it's a moot point.
> 
> FMOD comes with esound output driver, QEMU can (optionally) use FMOD and
> all its output drivers, latency will be horrible though.
> 
> QEMU_AUDIO_DRV=fmod QEMU_FMOD_DRV=esd qemu -enable-audio ...
> 

I wasn't aware of this. My old version of qemu certainly can't do this.
I'll have to try this out with fresh qemu CVS sometime soon.

By FMOD do you mean www.fmod.org ?

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[malc]

On Sun, 5 Dec 2004, Jim C. Brown wrote:

> On Mon, Dec 06, 2004 at 04:27:21AM +0300, malc wrote:
>>
>> Not at all what? Yes, there are sound daemons, but this does not change
>> the fact that there is no such concept as exclusive sound card lock, it
>> all comes down to what hardware is there behind /dev/dsp.
>
> I was simply saying that the story doesn't end with the limitations of the hardware.
>
>>> Of course, artsdsp doesn't work for qemu anyways, so it's a moot point.
>>
>> FMOD comes with esound output driver, QEMU can (optionally) use FMOD and
>> all its output drivers, latency will be horrible though.
>>
>> QEMU_AUDIO_DRV=fmod QEMU_FMOD_DRV=esd qemu -enable-audio ...
>>
>
> I wasn't aware of this. My old version of qemu certainly can't do this.
> I'll have to try this out with fresh qemu CVS sometime soon.
>
> By FMOD do you mean www.fmod.org ?

Yes. You have to configure QEMU properly though

P.S. fopen was never used to open /dev/dsp

-- 
mailto:malc@pulsesoft.com