DirectSound and i810 soundcards

[Francois Gouget]

Ove Kaaven wrote:
[...]
 > Basically the 'true' sample rate should be propagated back to
> dsound, so that it knows that the primary buffer is 48kHz and can resample
> secondary buffers accordingly. No changes is needed to dsound for this,
> wineoss's wodOpen just need to modify its waveformat input parameter if
> the WAVE_DIRECTSOUND flag is present, then dsound will happily convert
> secondary buffers to that sample rate when mixing them into the primary
> buffer.

Thanks. After realizing the SetFormat on the primary buffer was causing 
my half-baked fix to break, that worked fine. So I sent a patch to 
wine-patches.

I'm not really sure this is what Windows is doing however. I would be 
interested if people with Windows NT/2000/XP and an i810 soundcard could 
run both the dsound and the winmm tests and send me the output.

I believe that Windows lets you call SetFormat on the primary buffer but 
I'm not sure if that actually has an effect or not. Another thing i 
wonder about is whether Windows lets you play 11kHz sounds with 
WAVE_FORMAT_DIRECT using winmm and an i810 soundcard. If not then my 
winmm test is incorrect, and if yes then I have to wonder what 
WAVE_FORMAT_DIRECT really means. So if someone can send me these results...

Anyway, it works :-)

So now I'm trying to get the DirectSound test to work with i810 
soundcards+Alsa. The problem is that with this combination we fail to 
mmap the sound device:

err:wave:DSDB_MapPrimary (0x4038dcfc): Could not map sound device for 
direct access (Input/output error)

This can be simulated by adding the following to DSDB_MapPrimary in 
dlls/winmm/wineoss/audio.c:

         if (getenv("I810A"))
             wwo->mapping=(LPBYTE)-1;
         else
	wwo->mapping = mmap(NULL, wwo->maplen, PROT_WRITE, MAP_SHARED,
			    wwo->ossdev->fd, 0);

Then invoke the test with (quite handy to debug):
I810A="1" WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M 
dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c


I don't know why the mmap fails. I would tend to think this is a 
limitation or bug of the Alsa driver since it works with the OSS driver. 
However it seems that we should be able to cope with this situation. But 
I have some questions:

  * in wodOpen we create a wodPlayer thread... except if we are being 
called by DirectSound. Won't we need this thread if we cannot mmap the 
device?

  * when we do a SetFormat, DSOUND_PrimaryClose calls waveOutReset (only 
hwbuf, e.g. if mmap failed) which in turn calls OSS_AddRingMessage. 
However since we don't have the wodPlayer thread noone ever processes 
that message and we remain stuck there. What I'm currently experimenting 
with is not sending this message but I wonder if we should not make sure 
we have a wodPlayer thread instead (but then, when should we create it?).

  * the next problem is that DSOUND_PrimaryClose calls 
waveOutUnprepareHeader with a bunch of WAVEHDR pointers. Adding a test 
to avoid this condition is simple but again I wonder if this is quite 
normal. Am I right in thinking that this code path (hwbuf==NULL) is 
rarely if ever used? <g>


-- 
Francois Gouget
fgouget at codeweavers.com