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

[Andrew Eikum]

On Tue, Jan 22, 2013 at 11:15:59AM +0100, [e-mail] 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

[Alexandre Julliard]

Andrew Eikum  writes:
> On Tue, Jan 22, 2013 at 11:15:59AM +0100, [e-mail] 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.
> - 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.
> - 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.

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

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

[Alexandre Julliard]

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

[Alexandre Julliard]

 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.

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

[Francois Gouget]

On Tue, 22 Jan 2013, [e-mail] 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.