Comment 177 for bug 371897

(In reply to comment #71)
> At last, comments on the code itself :D
You'll get much more of them if you send patches (a series of patches not one big huge as you have here that's impossible to review) to wine-patches ML as RFC.

> For the second example cited from wine/dlls/winepulse.drv/dsoutput.c I'm not
> sure what you are trying to show, it looks alright to me. The first instance
> That->buffer = pa_xmalloc0(That->buffer_length) allocates the buffer through
> the libpulse function pa_xmalloc0 which initializes That->buffer to 0 and in
> the case off OOM terminates the application. Should HeapAlloc be used in this
> instance instead?
You can't allocate something via one method and free it via another one. pa_xmalloc0 and HeapAlloc do not allocate the same memory.

> As for the HeapFree() calls on That->buffer and *ippdsdb
> (which is the value of That), those calls are only reached on error:
Don't check for ptr != NULL before freeing it. HeapFree does that already.

No one shown arguments how pulseaudio any different then most other sound servers (other then minor cosmetic fixes accumulated over the years of arts/esd neglect). Any sound server is just that - a sound server that introduces extra latency and restricts direct sound access. If it can not be disabled programmatically then it's the sound server's bug, not application's that want to access sound directly.

> Please keep this bug report on topic: better interaction between pulseaudio and
> wine.
If you want to make it better fix pulseaudio to be properly suspendable when another applications needs ALSA. Not adding more layers on top. Or at least fix those layers to work properly.