Major mmdevapi and winmm audio bugs

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

[Andrew Eikum]

On Fri, Jan 20, 2012 at 05:43:15PM +0100, [e-mail] wrote:
> #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.

snd_device_name_hint() is probably what we want to use, but it's a
mess. It returns the same device many times (once for stereo,
surround40, surround41, surround51, etc).  Maybe we can try parsing
useful device names out of it, and kind of build a "capabilities
table" or something.

I don't know what to do here, which is why I've done nothing. I guess
a registry override would be "good enough" for 1.4.
> 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.

There's a registry entry users can use to disable sound entirely,
documented on the UsefulRegistryKeys page:
http://wiki.winehq.org/UsefulRegistryKeys
I don't think it's common enough to warrant space on the winecfg Audio
tab.
> #29299 need to play leading/trailing silence for ALSA block-oriented devices
> That takes various forms and can cause any affected app to hang.

This is mind-bendingly frustrating behavior from ALSA. Prefilling with
silence makes the most sense to me.
> #29585 OSS needs to be updated to be on par with ALSA refinements

I'm working on this. I'll attach patches later today.

Found yet another OSS annoyance, where:
    (bi.fragsize * bi.fragstotal > bi.bytes)
upon first creation, so it's hard to see how much data is in the OSS
buffer.
> #29305 one winmm device seems to stomp over the data of another one

I think you meant 29035. This one seems easy to fix, just need to take
a close look at it.
> - 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?)

This one's curious. Would be nice to have a trace to see what's going
wrong when they change X server.
> - DSound still bears traces of its former dependency on
> winmm blocks, not adequate with mmdevapi
> - semantics of DSound GetPosition

I'm working on this as well. Seems easy at first, but quite a lot of
the code depends on the GetPosition() stuff because that's how the
winmm-based code worked, so it requires some reworking.

Andrew