Major mmdevapi and winmm audio bugs

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

Again, the list is quite different from what I posted last month,
partly because of a shift in focus.

The good news is: judging from bugzilla, audio seems to work
much better since 1.3.36/37.

#29294 no sound with ALSA loopback
#28781 loopback to Jack
It is not acceptable for winealsa to solely know "default" and "hw:x,y".
The user can define and use any other name in the asound.conf files.
The old winealsa obeyed registry settings to override the card name(s).
IMHO, winealsa MUST provide such an override.  It is not acceptable
to replace "default" in dlls/winealsa.drv/mmdevdrv.c and recompile.

Furthermore, it was trivial with old winecfg to disable sound in a
compatible manner (= answers to API functions like from a native box
without sound).  What to do now? WINEDEBUG=mmdevapi= is not compatible.

W.r.t. configuration, what is the now recommended way for users to
self-diagnose MIDI issues?  In the ancient winecfg audio tab, Wine
would list their MIDI devices in device order, as I explained in
http://wiki.winehq.org/MIDI
Now users don't know what Wine chooses.
#8054 asked in 2007 already for an option to select the default
 MIDI device via winecfg (achievable via MIDIMap registry entry)

#29299 need to play leading/trailing silence for ALSA block-oriented devices
That takes various forms and can cause any affected app to hang.

#28273 handle "worst case little prefill/underrun" scenario well

#28039 MacOS GetPosition
#29657 MacOS memory management and dead-lock

#29585 OSS needs to be updated to be on par with ALSA refinements

#29305 one winmm device seems to stomp over the data of another one

#28388 Avoid SuspendThread, should be easy for me to fix, given time


There are issues not associated with a bug entry:

- Add run-time consistency checks in renderer and
  abort audio stream (GetBuffer) upon trouble instead of hanging.
- perhaps use AUDCLNT_E_DEVICE_INVALIDATED when we see PA restarted
  and have our DSound and winmm deal with that return code
  (Would that help #29369?)
- Mixer/Card recognition of some ALSA devices
- Check OSS4 with and without vmix #28056 #28790
- Investigate OSS4 underrun behaviour
- Check WHDR_BEGIN/ENDLOOP code and write tests
  (I know at least one bug involving waveOutBreakLoop)
- DSound still bears traces of its former dependency on
  winmm blocks, not adequate with mmdevapi
- semantics of DSound GetPosition

Winealsa's initial scanning of devices and the enumeration tests do
not produce reliable results because some high-level ALSA devices like
to cling to the underlying one for a couple of seconds.  Hence,
accessing "default" (routed to pulse) may block "hw:0" for ~3 seconds.

Of course there are more bugs than this.

Regards,
	Jörg Höhle