Alexandre Julliard wrote: >If PulseAudio can't provide good enumeration, then we can detect >that case and handle it differently. We don't ask PA to enumerate, we ask ALSA to enumerate.
Remembers me of the difficulties of enumerating /dev in Linux from user space: The problem is similar: open an unknown device and you can get unwanted side effects. >That doesn't mean we can break normal ALSA setups. It's not us. It can be argued that PA "keep it open for some time" breaks things. >My use case is a soundcard plus a USB headset; that's a fairly common setup >these days. [...] That works now, and it should continue to work. I believe you don't get the point. That does *not* work reliably in a setup that includes PulseAudio, because one cannot reliably scan ALSA devices and avoid side effects. As a result, Francois' machine behave randomly, as well as other ones (Dan Kegel's), go visit test.winehq.org:winmm:wave I do agree that it works well in other environments, e.g. dmix+hw:0+hw:1 Winealsa used to have AutoScanCards & ~Devices registry keys before mmdevapi times. http://source.winehq.org/source/dlls/winealsa.drv/waveinit.c?v=wine-1.3.24#L939 Perhaps we should reintroduce it? Here's a path: 1. Reintroduce AutoScanCards and/or AutoScanDevices. 2. Debate reasonable defaults. 3. Add winepulse, such that PA setups will use it and cannot deal with ALSA devices. 4. Have winealsa scan. So in some future, users without PA will use winealsa and see that device enumeration works for hw devices (not those from .asoundrc?). Users with PA will no more use winealsa. Users like me with PA present in Ubuntu but without PA headers hence no winepulse driver can disable scanning and get repeatable behavior. Regards, Jörg Höhle
