http://bugs.winehq.org/show_bug.cgi?id=28617
--- Comment #3 from GyB gyebro69@gmail.com 2011-10-17 13:35:04 CDT --- (In reply to comment #2)
Created attachment 36956 [details] dsound: Don't make the capture buffer object address public until it is prepared
(In reply to comment #1)
Created attachment 36769 [details] +tid,+winmm,+mmdevapi,+dsound,+alsa log
I wonder if these warnings might be related:
... warn:alsa:AudioClient_GetCurrentPadding Xrun detected ...
They're repeated several times in the log.
Nope. There's some problem creating the audio capture buffer. FlatOut2 apparently does no error checking, which results in the crash. You can see this in your log here (line 1385):
0009:trace:dsound:IDirectSoundCaptureImpl_CreateCaptureBuffer (0x3728d70,0x32fc74,0x6b0a20,(nil)) 0009:trace:dsound:IDirectSoundCaptureBufferImpl_Create (0x3728c80,0x6b0a20,0x32fc74) 0009:trace:dsound:IDirectSoundCaptureBufferImpl_Create (formattag=0x0001,chans=1,samplerate=8000,bytespersec=16000,blockalign=2,bitspersamp=16,cbSize=0) 0009:trace:mmdevapi:MMDevice_Activate (0x135100)->(0x5dd7f728,1,(nil),0x3728cdc) 0009:trace:alsa:AUDDRV_GetAudioEndpoint "default" 0x135100 1 0x3728cdc 0029:trace:dsound:IDirectSoundCaptureBufferImpl_GetCurrentPosition (0x3728f50,(nil),0x517ea4c) 0029:warn:dsound:IDirectSoundCaptureBufferImpl_GetCurrentPosition no driver 0029:trace:dsound:IDirectSoundCaptureBufferImpl_Lock (0x3728f50,00000000,00007998,0x517ea40,0x517ea54,0x517ea50,0x517ea30,0x00000000) at 1571 0029:trace:dsound:IDirectSoundCaptureBufferImpl_Lock invalid call 0029:trace:dsound:IDirectSoundCaptureBufferImpl_Lock returning 88780032 wine: Unhandled page fault on read access to 0x00000f9f at address 0x604702 (thread 0029), starting debugger...
Then a bit further down, you see thread 0009 resume with a successful MMDevice_Activate() call. So I think this is a concurrency issue. My guess is the game's audio capture thread (0029) continually checks for its IDirectSoundCaptureBuffer pointer to be non-NULL and starts working with it as soon as it is. Since our implementation assigns the buffer object directly to the pointer at allocation time, their capture thread takes it and tries to use the incomplete object before CreateCaptureBuffer() returns.
So here's a patch which only fills in the pointer on success. Does it fix the crash? If not, can you throw another log at me?
The patch indeed fixed the startup problem in FlatOut 2, when DirectSound driver was selected in the launcher. Tested with wine-1.3.30-145-g7a4349b. I should have mentioned that despite of the crash sometimes the game just starts fine (and audio is working in the game). Most of the times the crash is fatal. Thanks for taking time to read through the logs and creating the patch.