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