RFC: Remove auto-scan of ALSA devices from winealsa.drv (and get repeatable behaviour)

Joerg-Cyril.Hoehle at t-systems.com Joerg-Cyril.Hoehle at t-systems.com
Tue Jan 22 12:11:23 CST 2013

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.
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.

	Jörg Höhle

More information about the wine-devel mailing list