Major mmdevapi and winmm audio bugs

[Andrew Eikum]

On Fri, Jan 20, 2012 at 05:43:15PM +0100, Joerg-Cyril.Hoehle at t-systems.com 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