RFC: Remove auto-scan of ALSA devices from winealsa.drv (and get repeatable behaviour)
Hi, please view the winmm:wave test results from Francois Gouget's machines fg-acer64-t32 fg-acer64-wow32 fg-acer64-t64 fg-acer64-wow64 http://test.winehq.org/data/dabde6a04f6d02233bc5074a8eba613b2c4adc68/index_L... Is their configuration the same except for 32/64bit? We see 3 types of results 2x: 2 devices, no ALSA "default" device(!), one HDA-An, one HDA-HDMI 1x: 3 devices incl. ALSA "default", all tests successful 1x: 3 devices incl. ALSA "default", dev. 1 HDA-An yields MMSYSERR_ALLOCATED Is their configuration truly the same? Is that yet another aretefact of ALSA device enumeration? It could well be. Again, I argue in favor of removing the enumeration code. I want users to get repeatable results. I don't want Wine's winmm to map device 0 as ALSA "default" on one run and "HDMI-An" on another run. Andrew Eikum was in favour of this too and since implemented winmm device notification upon change. Remember the December thread: http://www.winehq.org/pipermail/wine-devel/2012-December/098114.html Of course, the winecfg/GUI issue need be addressed. Regards, Jörg Höhle
On Tue, Jan 22, 2013 at 11:15:59AM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
Andrew Eikum was in favour of this too and since implemented winmm device notification upon change. Remember the December thread: http://www.winehq.org/pipermail/wine-devel/2012-December/098114.html
Yeah, I still think it's a good idea. Assuming we remove enumeration and add a good UI to manually add devices, there were two unanswered objections raised in the last thread. 1) We still want to do this, but want a better way to do this (i.e. work with upstream to make a good enumeration API) This still requires us to gut our existing enumeration, so I guess you can think of it in two pieces: remove the existing enumeration, and add "good" enumeration should that ever exist. So let's do step one now and maybe step two if it becomes possible. 2) Each new prefix will require manual configuration This is true now, but it would be a larger pain if the user has to add a device in addition to selecting it. Is there some existing mechanism for users to customize prefixes when they're created? Should there be? Anyway, I'll put this on my TODO list and let you know when I've got something working. Andrew
Andrew Eikum <aeikum(a)codeweavers.com> writes:
On Tue, Jan 22, 2013 at 11:15:59AM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
Andrew Eikum was in favour of this too and since implemented winmm device notification upon change. Remember the December thread: http://www.winehq.org/pipermail/wine-devel/2012-December/098114.html
Yeah, I still think it's a good idea. Assuming we remove enumeration and add a good UI to manually add devices, there were two unanswered objections raised in the last thread.
1) We still want to do this, but want a better way to do this (i.e. work with upstream to make a good enumeration API)
This still requires us to gut our existing enumeration, so I guess you can think of it in two pieces: remove the existing enumeration, and add "good" enumeration should that ever exist. So let's do step one now and maybe step two if it becomes possible.
2) Each new prefix will require manual configuration
This is true now, but it would be a larger pain if the user has to add a device in addition to selecting it. Is there some existing mechanism for users to customize prefixes when they're created? Should there be?
I still fail to see how this would be an improvement. If the enumeration doesn't give good results in some cases the heuristics could be improved, and/or fixed upstream, but getting rid of it is not a solution. At least on my setup, the current code is working just fine, and offering the devices I expect, without any manual configuration. That's how it should work for everybody. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
At least on my setup, the current code is working just fine, and offering the devices I expect, without any manual configuration. Are you using PulseAudio? I believe that *every* user with PulseAudio is bound to see the flakiness that happened on Francois' machine. So from these users' (Ubuntu, Fedora?) POV, the current code is not the _least_ working fine.
I do agree that a clickable list of ALSA devices is nicer to handle than "Please enter the names of your ALSA device(s) into this textfield if it is not simply "default". OTOH, "default" should be enough for the large majority of users, and there should be no need in many, many use cases to go and seek another device name like: - surround51 - 5:1 users will need to add something like that, sorry - some_jack_device - Jack users will know their ALSA device names because they need to configure other Jack-ALSA using applications anyway. - any other use case???
Each new prefix will require manual configuration No. "default" should work OOTB on any sane Linux desktop setup. It's only "advanced" usage beyond "default" that requires manual intervention. (well, using 5:1 should not count as advanced, but my understanding of typical desktop setups with 5:1 cards is that ALSA's "default" only yields 2 channels?)
Regards, Jörg Höhle
<Joerg-Cyril.Hoehle(a)t-systems.com> writes:
Alexandre Julliard wrote:
At least on my setup, the current code is working just fine, and offering the devices I expect, without any manual configuration. Are you using PulseAudio? I believe that *every* user with PulseAudio is bound to see the flakiness that happened on Francois' machine. So from these users' (Ubuntu, Fedora?) POV, the current code is not the _least_ working fine.
If PulseAudio can't provide good enumeration, then we can detect that case and handle it differently. That doesn't mean we can break normal ALSA setups.
I do agree that a clickable list of ALSA devices is nicer to handle than "Please enter the names of your ALSA device(s) into this textfield if it is not simply "default".
OTOH, "default" should be enough for the large majority of users, and there should be no need in many, many use cases to go and seek another device name like: - surround51 - 5:1 users will need to add something like that, sorry - some_jack_device - Jack users will know their ALSA device names because they need to configure other Jack-ALSA using applications anyway. - any other use case???
My use case is a soundcard plus a USB headset; that's a fairly common setup these days. I want to see both devices in apps that offer device selection, and pick the one appropriate for that app, without messing with winecfg. That works now, and it should continue to work. -- Alexandre Julliard julliard(a)winehq.org
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#L... 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
<Joerg-Cyril.Hoehle(a)t-systems.com> writes:
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.
I know that. It doesn't mean we can't use a heuristic to detect broken PA enumeration.
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.
Yes, I got the point. You are saying that because PA is broken, you want to break the ALSA driver even when PA is not in use. That's not a solution. -- Alexandre Julliard julliard(a)winehq.org
On Tue, 22 Jan 2013, Joerg-Cyril.Hoehle(a)t-systems.com wrote: [...]
We see 3 types of results 2x: 2 devices, no ALSA "default" device(!), one HDA-An, one HDA-HDMI 1x: 3 devices incl. ALSA "default", all tests successful 1x: 3 devices incl. ALSA "default", dev. 1 HDA-An yields MMSYSERR_ALLOCATED
Is their configuration truly the same? Is that yet another aretefact of ALSA device enumeration? It could well be.
As far as hardware-level and configuration yes. The tests are run in sequence with just a wipe of ~/.wine in between them. It looks like I don't have the 32-bit libasound2-plugins package installed (nothing indicates that it might be needed at compile time or at run time). Could that be the source of the 2 vs. 3 devices difference? libasound2:amd64 1.0.25-4 libasound2:i386 1.0.25-4 libasound2-dev:amd64 1.0.25-4 libasound2-dev:i386 1.0.25-4 libasound2-plugins:amd64 1.0.25-2 I have no idea as to the cause of the MMSYSERR_ALLOCATED error. All I can say is I did not touch the laptop while it was running the tests. Looking at the history it also happened to the 32-bit tests on my desktop (so it's not 64-bit specific) and appears to be quite random. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean
participants (4)
-
Alexandre Julliard -
Andrew Eikum -
Francois Gouget -
Joerg-Cyril.Hoehle＠t-systems.com