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

["Jim C. Brown" <jbrown106@phreaker.net>]

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.