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