Sound on TestBot

Greg Geldorp wrote:
> I've found a way to add a soundcard to most of the TestBot VMs (using
> the virtual soundcard driver from VMware View).

This is excellent news. It even has MIDI-out!

Alas,
capture.c:661: found 0 WaveIn devices
means that most mci.c tests (which are mostly mciwave tests) are skipped
because the tests depend on the ability to record, then play back.
mci.c:651: Tests skipped: Please install audio driver. Everything is skipped.


Hopefully Francois Gouget will update his vmware machines with these
drivers (or the ones Paul Vriens' uses) so that the timeouts will disappear.
http://test.winehq.org/data/190c3518d66df44cfa464d8dc1ca3fd50ff6c361/xp_fg-w...

Earlier this year, Julius Schwartzenberg found out that the timeouts in
winmm tests on vmware could be avoided by installing another driver.
http://www.winehq.org/pipermail/wine-devel/2010-March/082118.html


capture.c:674: Test failed: waveInGetDevCapsA(WAVE_MAPPER): got MMSYSERR_NOERROR
capture.c:691: Test failed: waveInGetDevCapsW(1): got MMSYSERR_NOERROR
Weird. waveOutGetDevCaps (in wave.c) behaves as expected. Looks like a driver bug.

Perhaps one explanation for the WAVE_MAPPER case is found in my mci.c tests:
     * However some w2k8/w7 machines return no error when there's no wave
     * input device (perhaps querying waveOutGetNumDevs instead of waveIn?),
     * still the record command below fails with MCIERR_WAVE_INPUTSUNSUITABLE.
     * Don't skip here, record will fail below. */
    err = mciSendString("set x format tag pcm", NULL, 0, NULL);

I should feed testbot a patch to call wave_in_test_device(1)
despite numdevs=0 to see what happens.

Regards,
 Jörg Höhle

[Greg Geldorp]

> From: Jörg Höhle
>
> Hopefully Francois Gouget will update his vmware machines with these
> drivers (or the ones Paul Vriens' uses) so that the timeouts will
> disappear.

http://test.winehq.org/data/190c3518d66df44cfa464d8dc1ca3fd50ff6c361/xp_fg-w
inxp-sp3/winmm:midi.html
> Earlier this year, Julius Schwartzenberg found out that the timeouts in
> winmm tests on vmware could be avoided by installing another driver.
> http://www.winehq.org/pipermail/wine-devel/2010-March/082118.html

Note that most people probably use VMware Workstation. Workstation emulates
an
SoundBlaster (I think?) card, so there's actually virtual hardware in there.
This means you can install a normal SoundBlaster driver, the driver will
send
commands to the virtual hardware device which are then picked up by the
Workstation virtual hardware layer.

TestBot uses (mostly) VMware ESX VMs, which do not have virtual hardware
devices
for sound. The sound drivers I'm adding to the ESX VMs are pure virtual
drivers,
there's no (virtual) hardware below them.

Ge.

[Francois Gouget]

On Fri, 17 Sep 2010, Greg Geldorp wrote:
[...]
> Note that most people probably use VMware Workstation. Workstation 
> emulates an SoundBlaster (I think?) card, so there's actually virtual 
> hardware in there. This means you can install a normal SoundBlaster 
> driver, the driver will send commands to the virtual hardware device 
> which are then picked up by the Workstation virtual hardware layer.

Yes, I use VMware Workstation which emulates a Sound Blaster PCI 128 
sound card: depending on the place the driver is either called 'Creative 
AudioPCI (ES1371,ES1373)' or 'Creative Sound Blaster PCI'.

Strangely enough, my Win9x VMs use the same driver (but only older and 
for win9x obviously) and although they all have a Midi device, none of 
them seems to get stuck in the midi test. Only the Windows XP and NT4 
VMs seem to have trouble.

I tried commenting out all the UART lines in wdma_ens.inf in Windows XP 
as described in 
http://www.winehq.org/pipermail/wine-devel/2010-March/082116.html but 
this had no effect. I also tried reinstalling the device afterwards (by 
deleting it in the device manager and letting XP redetect it), but to no 
avail.

The driver's Properties tab in the hardware device manager gave me some 
hope because it has a 'Do not use MIDI features on this device' radio 
button. However checking it disables the driver entirely :-(

So unless someone else finds a solution maybe the route to go is to 
apply this patch: 
http://www.winehq.org/pipermail/wine-devel/attachments/20100302/ac1a08e3/att...



-- 
Francois Gouget <fgouget(a)free.fr>              http://fgouget.free.fr/
        War doesn't determine who's right.  War determines who's left.