Major mmdevapi and winmm audio bugs

[Jari Vetoniemi]

Interesting,
It looks like bug #28982, could be affected by one or more of these you listed.

2011/12/16  <Joerg-Cyril.Hoehle at t-systems.com>:
> Hi,
>
> The present list is quite different from what I posted 2 month ago.
> http://www.winehq.org/pipermail/wine-devel/2011-October/092716.html
>
> #28723 is about handling tight timing and little prefill
>
> #27901 is about snd_pcm_drop erroneously being used by AudioClient_Stop.
> I've a patch in my queue but it depends on the "small buffer" patch discussed in #28723.
>
> #29056
> #29299 are the major "ALSA won't start without period-size frames" issue
>  That can cause any affected app to hang.
>
> #29305 one winmm device seems to stomp over the data of another one
>
> # OSS needs to be updated to be on par with ALSA refinements
>
> #28093 MacOS GetCurrentPadding
> #28039 MacOS GetPosition (neeed to recheck)
>
> #28388 Avoid SuspendThread, should be easy for me to fix, given time
>
>
> There are QA issues not associated with a bug entry:
>
> - Add run-time consistency checks in renderer and
>  abort audio stream (GetData) upon trouble instead of hanging.
> - OSS GetPosition from DSP_GETODELAY
> - ALSA+OSS: ReleaseBuffer: enforce method ordering and max size like CoreAudio
> - wineoss GetStreamLatency must be constant, and SNDCTL_DSP_GETODELAY
>  is only usable once running
> - Investigate OSS4 underrun behaviour
> - Check WHDR_BEGIN/ENDLOOP code and write tests
>
> and finally:
>
> - Test compatibility with native DSound and file bug if unusable.
> There are several reports in bugzilla mentioning that this
> work-around ceased to work since 1.3.25.  Loss of interoperability
> is not acceptable.
>
> Of course there are more bugs than this.
>
> Regards,
>        Jörg Höhle
>