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>