On Fri, Jan 20, 2012 at 05:43:15PM +0100, [email protected] 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
