Op 31-12-12 20:01, Andrew Eikum schreef: > On Mon, Dec 31, 2012 at 07:03:31PM +0100, Maarten Lankhorst wrote: >> Op 31-12-12 17:59, Andrew Eikum schreef: >>> On Sat, Dec 29, 2012 at 01:24:03AM +0100, Maarten Lankhorst wrote: >>>> + if(!maxq){ >>>> + /* nothing to do! */ >>>> + LeaveCriticalSection(&device->mixlock); >>>> + return; >>>> } >>> This was removed in 8ba4090fc304993. It breaks starting the device in >>> some situations (write primary mode iirc). >> Writeprimary dsound tests still worked for me, I don't particulary care >> though, if you want I'll zap it. >> After rework fail it should no longer matter.. >> > Zaxxon (see Bug 30836) shows the problem on some, but not all, > systems. Anyway, PerformMix() does more than just mix and write data, > so returning early only because we have no frames to write is not > always correct. > >>>> + if (native) { >>>> + void *buffer = NULL; >>>> + >>>> + hr = IAudioRenderClient_GetBuffer(device->render, maxq >>>> / block, (void*)&buffer); >>>> + if(FAILED(hr)){ >>>> + WARN("GetBuffer failed: %08x\n", hr); >>>> + LeaveCriticalSection(&device->mixlock); >>>> + return; >>>> + } >>> I think this (mixing directly to RenderClient and skipping WaveQueue) >>> could be split into a separate patch. >> Hate to sound like a broken record here, but the whole mixer logic breaks if >> you touch that code. :/ >> > Really? It looks like an optimization to me: mix directly into the > RenderClient buffer instead of to the intermediary buffer if the > target format is float. What breaks if we use the intermediary buffer > in every case? > I suppose the if native branch could be taken out, but that's not nearly as interesting as the other changes I was making in that function, and not nearly as likely to mess up anything.
~Maarten