RFC: Remove auto-scan of ALSA devices from winealsa.drv
Hi, Here's my proposal: winealsa shall stop enumerating ALSA devices. By default, it should solely provide access to ALSA's default device adequately named "default". The code that currently scans the registry Software\Wine\Drivers\winealsa.drv\devices=... shall remain in place, allowing a comma-separated list of alternate ALSA device names for those setups where "default" is not the preferred ALSA choice. Rationale: ALSA front-ends (pulse, dmix etc.) compete for the few back-ends (one or 2 sound cards or audio plugs). Some front-ends cling to the back ends even when unused. This has been known to cause random bugs. - Test suites failing randomly ("resource temporarily unavailable") e.g. bug #28109, #28048 or randomly performing more or less tests, depending on whether the app managed to open the device or not. - Sound stopping in apps (I believe when transitioning from intros to the main menu or game, at which time a rescan of all audio devices happens as mmdevapi is reopened). Nobody found an elegant way to robustly enumerate ALSA devices (some apps hard-wire common names...), so let's simply avoid the issue entirely. On many systems, the current code enumerates a quite uninteresting set of devices, e.g. "default", "plughw:0" and "plughw:4". These days, who wants hw:0 without mixing? I never heard any sound from "hw:4". The current code fails to enumerate some existing devices like "plug:dmix". OTOH, enumerating solely "default" or the user's hand-edited list of devices is expected to provide repeatable and best results. Cost to users: Users with a working ALSA device "default" should experience no drawback, only benefits. I believe this is the vast majority of users. Users that edit their ~/.asoundrc to define other devices without simultaneously overriding !default will have to additionally edit the Wine registry to name their working ALSA capture and render devices, e.g. "asnoop" and "amix". winecfg may or may not provide a GUI for editing this. This would be similar to most multimedia players allowing some way to change the ALSA device to use. It's a pity that the registry scheme AFAIK does not allow per-app audio settings, but that's a completely unrelated issue. Cost of non-adoption: Users and audio devs remain annoyed. Bug reports remain open. Unpredictable and erratic loss of sound possible each time mmdevapi rescans the ALSA devices. Please comment, Jörg Höhle
On 11 December 2012 16:05, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Cost to users:
Users with a working ALSA device "default" should experience no drawback, only benefits. I believe this is the vast majority of users.
Users that edit their ~/.asoundrc to define other devices without simultaneously overriding !default will have to additionally edit the Wine registry to name their working ALSA capture and render devices, e.g. "asnoop" and "amix".
It will also pretty much just remove device selection on setup with multiple audio devices, which is actually fairly common these days with USB audio devices and HDMI outputs on graphics cards. I think the correct approach would to work with upstream ALSA to fix things, instead of just removing device enumeration.
On 12/11/2012 10:46 AM, Henri Verbeet wrote:
On 11 December 2012 16:05, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Cost to users:
Users with a working ALSA device "default" should experience no drawback, only benefits. I believe this is the vast majority of users.
Users that edit their ~/.asoundrc to define other devices without simultaneously overriding !default will have to additionally edit the Wine registry to name their working ALSA capture and render devices, e.g. "asnoop" and "amix".
It will also pretty much just remove device selection on setup with multiple audio devices, which is actually fairly common these days with USB audio devices and HDMI outputs on graphics cards. I think the correct approach would to work with upstream ALSA to fix things, instead of just removing device enumeration.
I do not think this is a particularly good idea. I do have two sound systems on my machine and I have assigned each to different roles. That seems to work quite well. What does not work well is leaving the role set to 'default'. That results in the selection of the highest latency device with corresponding stutters and over-runs. The current requirement for selecting an output device is mildly annoying, but no where near as annoying as being forced to use a faulty device.
On Tue, Dec 11, 2012 at 9:39 AM, Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote:
On 12/11/2012 10:46 AM, Henri Verbeet wrote:
On 11 December 2012 16:05, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Cost to users:
Users with a working ALSA device "default" should experience no drawback, only benefits. I believe this is the vast majority of users.
Users that edit their ~/.asoundrc to define other devices without simultaneously overriding !default will have to additionally edit the Wine registry to name their working ALSA capture and render devices, e.g. "asnoop" and "amix".
It will also pretty much just remove device selection on setup with multiple audio devices, which is actually fairly common these days with USB audio devices and HDMI outputs on graphics cards. I think the correct approach would to work with upstream ALSA to fix things, instead of just removing device enumeration.
I do not think this is a particularly good idea. I do have two sound systems on my machine and I have assigned each to different roles. That seems to work quite well. What does not work well is leaving the role set to 'default'. That results in the selection of the highest latency device with corresponding stutters and over-runs. The current requirement for selecting an output device is mildly annoying, but no where near as annoying as being forced to use a faulty device.
You'd still be able to select a different device in the registry. -- -Austin
On 12/11/2012 02:11 PM, Austin English wrote:
On Tue, Dec 11, 2012 at 9:39 AM, Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote:
On 12/11/2012 10:46 AM, Henri Verbeet wrote:
It will also pretty much just remove device selection on setup with multiple audio devices, which is actually fairly common these days with USB audio devices and HDMI outputs on graphics cards. I think the correct approach would to work with upstream ALSA to fix things, instead of just removing device enumeration.
I do not think this is a particularly good idea. I do have two sound systems on my machine and I have assigned each to different roles. That seems to work quite well. What does not work well is leaving the role set to 'default'. That results in the selection of the highest latency device with corresponding stutters and over-runs. The current requirement for selecting an output device is mildly annoying, but no where near as annoying as being forced to use a faulty device.
You'd still be able to select a different device in the registry.
Replacing the ability to use a drop box in the app to select the audio device with a 'regedit' session is not an improvement. On the other hand, I may not understand the impact of this proposal...
On Tue, Dec 11, 2012 at 04:46:34PM +0100, Henri Verbeet wrote:
On 11 December 2012 16:05, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
My first reaction is that this is a good idea. We've had some discussion about device enumeration before. The final conclusion was it's basically impossible to do usefully with ALSA. I can't think of a way for us or for ALSA to enumerate only "useful" devices. The closest that currently exists is snd_device_name_hint, but that has plenty of problems, too: http://www.winehq.org/pipermail/wine-devel/2012-February/094182.html For comparison, here's some examples of what various libraries and applications do: snd_device_name_hint: aplay, VLC Hard-coded based on number of channels: mplayer, SDL snd_card_next: Wine, gstreamer There is clearly no consensus.
Cost to users:
Users with a working ALSA device "default" should experience no drawback, only benefits. I believe this is the vast majority of users.
Users that edit their ~/.asoundrc to define other devices without simultaneously overriding !default will have to additionally edit the Wine registry to name their working ALSA capture and render devices, e.g. "asnoop" and "amix".
It will also pretty much just remove device selection on setup with multiple audio devices, which is actually fairly common these days with USB audio devices and HDMI outputs on graphics cards. I think the correct approach would to work with upstream ALSA to fix things, instead of just removing device enumeration.
It's tricky because ALSA and PulseAudio have different theories about where device selection should occur -- in the application or in the audio mixer. In the ALSA case, we want to list devices. In the Pulse case, we want to list only "default". The fact that ALSA still doesn't have a usable enumeration API makes me think that enumeration is not an intended use-case. The official ALSA sample applications tend to use "default" or allow the user to specify their own device. That seems like a fine compromise. So it seems reasonable to me to list only "default", but also provide an easy way to add new devices. Forcing users like Max to go to regedit in every new prefix to add a new audio device really sucks. This means some sort of driver-specific dialog in winecfg (or control panel?). That sucks too, but I think it's the least-bad solution. Andrew
On 12 December 2012 15:28, Andrew Eikum <aeikum(a)codeweavers.com> wrote:
It's tricky because ALSA and PulseAudio have different theories about where device selection should occur -- in the application or in the audio mixer. In the ALSA case, we want to list devices. In the Pulse case, we want to list only "default".
But supposedly we'll have a winepulse driver eventually, so winealsa would only need to care about actual ALSA devices.
Hi, Henri Verbeet suggested:
But supposedly we'll have a winepulse driver eventually, so winealsa would only need to care about actual ALSA devices. Alas, it's only after you opened the device that you can discover that it's PulseAudio, at which time it is too late. Also, I don't know if PA is the only front-end with such weird side-effects.
Max TenEyck Woodbury objected:
Replacing the ability to use a drop box in the app to select the audio device with a 'regedit' session is not an improvement. My proposal intentionaly was silent about GUI changes, but you are right: in such a case, winecfg should provide a textedit box for users to enter a (or edit the registry's) comma-separated list of ALSA device names. I'm not sure if winecfg is currently sufficiently detached from winmm/mmdevapi for such editing to take effect immediately. I remember bugs where the "Test Sound" button would continue to use the previously selected device.
Regards, Jörg Höhle
On 12 December 2012 16:23, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Henri Verbeet suggested:
But supposedly we'll have a winepulse driver eventually, so winealsa would only need to care about actual ALSA devices. Alas, it's only after you opened the device that you can discover that it's PulseAudio, at which time it is too late.
You'd never even load winealsa.
On Wed, Dec 12, 2012 at 04:23:52PM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
Max TenEyck Woodbury objected:
Replacing the ability to use a drop box in the app to select the audio device with a 'regedit' session is not an improvement. My proposal intentionaly was silent about GUI changes, but you are right: in such a case, winecfg should provide a textedit box for users to enter a (or edit the registry's) comma-separated list of ALSA device names. I'm not sure if winecfg is currently sufficiently detached from winmm/mmdevapi for such editing to take effect immediately. I remember bugs where the "Test Sound" button would continue to use the previously selected device.
That stuff requires IMMNotificationClient, which I actually do have an implementation of, but I'm not quite happy with it yet. I don't think lacking that interface prevents us from doing this particular enhancement, though. Andrew
On Wed, Dec 12, 2012 at 03:57:40PM +0100, Henri Verbeet wrote:
On 12 December 2012 15:28, Andrew Eikum <aeikum(a)codeweavers.com> wrote:
It's tricky because ALSA and PulseAudio have different theories about where device selection should occur -- in the application or in the audio mixer. In the ALSA case, we want to list devices. In the Pulse case, we want to list only "default".
But supposedly we'll have a winepulse driver eventually, so winealsa would only need to care about actual ALSA devices.
Even ignoring the Pulse case, we don't have an acceptable enumeration API. It doesn't seem unreasonable to require users with strange audio setups to tell Wine what to do. We could provide some convenience features, like a list of suggested devices that the user would have to explicitly enable. Andrew
On Wed, Dec 12, 2012 at 04:45:11PM +0100, Henri Verbeet wrote:
On 12 December 2012 16:31, Andrew Eikum <aeikum(a)codeweavers.com> wrote:
Even ignoring the Pulse case, we don't have an acceptable enumeration API. Yes, I know. I just don't think it would be unreasonable to try to work with ALSA upstream to fix that.
I asked about this topic back in January and didn't really receive a useful response: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-January/047821.htm... In fact, Jörg's original question was basically ignored: http://thread.gmane.org/gmane.linux.alsa.devel/92878/focus=92923 There doesn't seem to be much motivation to fix this. I know the ALSA devs are working on a channel mapping API, which will (probably?) make the surroundXX interfaces obsolete. I've been trying to think of a way to define "useful ALSA interface," and I'm coming up blank. Should it just be all of "plug:'CARD=ABC,DEV=n'" and all interfaces in various asoundrc? Do we wait until the channel mapping API is in so we can obsolete the surroundXX stuff? What about other plugins like "dmix"? Are those useful to enumerate? Is there a way to enumerate plugins? I think the problem is complicated enough and unimportant enough that it's not really on anyone's plate. Meanwhile Wine displays useless devices. Andrew
On 12/11/2012 08:46 AM, Henri Verbeet wrote:
On 11 December 2012 16:05, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Cost to users:
Users with a working ALSA device "default" should experience no drawback, only benefits. I believe this is the vast majority of users.
Users that edit their ~/.asoundrc to define other devices without simultaneously overriding !default will have to additionally edit the Wine registry to name their working ALSA capture and render devices, e.g. "asnoop" and "amix".
It will also pretty much just remove device selection on setup with multiple audio devices, which is actually fairly common these days with USB audio devices and HDMI outputs on graphics cards. I think the correct approach would to work with upstream ALSA to fix things, instead of just removing device enumeration.
Can winecfg use a special interface into winealsa & co to enumerate available devices? But change winealsa to use "default" device otherwise? - Vitaliy
participants (6)
-
Andrew Eikum -
Austin English -
Henri Verbeet -
Joerg-Cyril.Hoehle＠t-systems.com -
Max TenEyck Woodbury -
Vitaliy Margolen