(In reply to comment #335)
> FWIW, feedback on the forum is that this is fixed.
Which one of "this" is supposed to be fixed?
> If the minimum version of alsa-plugins needed is 1.0.24 (comment 331)...
Read my comment once again: absolute minimum is 1.0.24 as with earlier versions you wouldn't get any sound at all from Wine+ALSA+PA combo (or it would hang very quickly, see bugs #28282 and #28066).
Typical error message for too old alsa-plugins version is something like:
ALSA lib pcm_pulse.c:1008:(_snd_pcm_pulse_open) Unknown field handle_underrun
Since the release of the alsa-plugins v.1.0.24 there were a lot of other PA-related fixes commited into git so one wishing to get best of it have to download, compile and install git HEAD version of alsa-plugins. Actually it should be done by distro package maintainers as alsa-plugins release cycle seems to be too slow to deliver fixes timely to the users who need them.
(In reply to comment #334)
> I thought that PulseAudio is in charge of everything by default, and
> when an app (like Wine) thinks it's using ALSA in this setup, it's actually
> using a wrapper provided by PulseAudio that translates ALSA calls to PulseAudio
> calls?
It's actually a bit mixed. Apps are expected to use ALSA through a thing called "alsalib" (a.k.a. "libalsa"). This thing supports a concept of "plugins" (which are called - you guess - alsa plugins). Good examples of plugin are dmix and plug which are well-known to anyone who had ever been hand-configuring ALSA using asoundrc. Another example of alsa-plugin is a "pulse" plugin which is also provided by ALSA dev-team. This plugin acts as forward mechanism towards PA. Most of the problems with PA usually were caused by bugs in PA itself. On the other hands some bugs were caused by deficiency in pulse alsa-plugin. Yeah, I know that "The Big Picture of the Sound Subsystem" is a bit complicated in ALSA+PA enabled world :-).
(In reply to comment #335)
> FWIW, feedback on the forum is that this is fixed.
Which one of "this" is supposed to be fixed?
> If the minimum version of alsa-plugins needed is 1.0.24 (comment 331)...
Read my comment once again: absolute minimum is 1.0.24 as with earlier versions you wouldn't get any sound at all from Wine+ALSA+PA combo (or it would hang very quickly, see bugs #28282 and #28066).
Typical error message for too old alsa-plugins version is something like: c:1008: (_snd_pcm_ pulse_open) Unknown field handle_underrun
ALSA lib pcm_pulse.
Since the release of the alsa-plugins v.1.0.24 there were a lot of other PA-related fixes commited into git so one wishing to get best of it have to download, compile and install git HEAD version of alsa-plugins. Actually it should be done by distro package maintainers as alsa-plugins release cycle seems to be too slow to deliver fixes timely to the users who need them.
(In reply to comment #334)
> I thought that PulseAudio is in charge of everything by default, and
> when an app (like Wine) thinks it's using ALSA in this setup, it's actually
> using a wrapper provided by PulseAudio that translates ALSA calls to PulseAudio
> calls?
It's actually a bit mixed. Apps are expected to use ALSA through a thing called "alsalib" (a.k.a. "libalsa"). This thing supports a concept of "plugins" (which are called - you guess - alsa plugins). Good examples of plugin are dmix and plug which are well-known to anyone who had ever been hand-configuring ALSA using asoundrc. Another example of alsa-plugin is a "pulse" plugin which is also provided by ALSA dev-team. This plugin acts as forward mechanism towards PA. Most of the problems with PA usually were caused by bugs in PA itself. On the other hands some bugs were caused by deficiency in pulse alsa-plugin. Yeah, I know that "The Big Picture of the Sound Subsystem" is a bit complicated in ALSA+PA enabled world :-).