This subject was discussed a few months ago (around 10/2007). But it was rather a discussion about whether to make a PA sound driver or not. I personally would love to see that happen, if not only because PA has some very nifty features, like per-app volume, transparent sink switching etc, some of which are impossible to emulate through the alsa pulse plugin. Also, then next Ubuntu and Fedora releases will have PA enabled by default so if Wine doesn't work with that well there will be complaints.
I switched my desktop to PA yesterday, got most apps working, and to my surprise even flash (netscape 32bit plugin in a 64bit browser). All apps that I need use PA natively, only Wine doesn't have a PA sound driver. Since winealsa.drv will stay the default driver for Linux for the foreseeable future, I started digging and hacking to see why it doesn't work with the alsa pulse plugin and what can be fixed. There are a few bug reports that track the winealsa.drv/PA issue, such as [1].
There is very little required to make it work. Only two tiny changes to the alsa pulse plugin (one can be described as a quirk, until I figure out how exactly the alsa API can be emulated using PA, seems to be a very specific issue in how Wine uses the alsa API since other apps work fine) and sound works perfectly (tested with foobar2000 and WoW, both playback and recording). alsa-1.0.16 was just released, so I hope the needed changes make it into the next version.
In the PA volume control, all wine apps show up under the same name: ALSA plug-in [wine-preloader] and thus share the same volume and sink preferences. The alsa plugin could try to do some /proc/self voodoo to extract the true exe name. But given the simplicity of the PA API (no hwparams negotiation, just request a format and you'll get it) and the current problems with the alsa pulse plugin, I think a true wine sound driver would be a viable alternative. I'm still waiting to hear from those people who have said that they have a wine PA driver working :)
tom
Am Freitag, 22. Februar 2008 01:50:09 schrieb Tomas Carnecky:
I switched my desktop to PA yesterday, got most apps working, and to my surprise even flash (netscape 32bit plugin in a 64bit browser). All apps that I need use PA natively, only Wine doesn't have a PA sound driver.
The point was and is that we don't want yet another half working sound backend in Wine. We will have to maintain the Alsa one because there are things PA won't be able to give us by design, like HW mixing and lowest-latency direct access which is needed for gaming.
Of course, as you said, if someone has patches and intends to maintain it we're happy to accept it. But I think none of the current Wine sound developers(aka Maarten) has any intentions to spend time on a PA backend.
Stefan Dösinger wrote:
Am Freitag, 22. Februar 2008 01:50:09 schrieb Tomas Carnecky:
I switched my desktop to PA yesterday, got most apps working, and to my surprise even flash (netscape 32bit plugin in a 64bit browser). All apps that I need use PA natively, only Wine doesn't have a PA sound driver.
The point was and is that we don't want yet another half working sound backend in Wine. We will have to maintain the Alsa one because there are things PA won't be able to give us by design, like HW mixing and lowest-latency direct access which is needed for gaming.
HW mixing is overrated :) Current CPUs can do the mixing just as well, if not with a even better quality. I don't say it's useless as I'm sure professionals have a good reason to use high-end cards with high-quality mixers (but they should use wineasio or winejack anyway). Also, PA ideally only adds less then 1ms of latency, that's hardly an issue, even in gaming. Mind you, I don't say winealsa should go away, I'm just saying PA isn't as bad as it looks.
Of course, as you said, if someone has patches and intends to maintain it we're happy to accept it. But I think none of the current Wine sound developers(aka Maarten) has any intentions to spend time on a PA backend.
Wineasio is maintained as an external component, so I guess winepulse could be too. There are enough free git repo providers around.
tom
On Fri, Feb 22, 2008 at 01:50:09AM +0100, Tomas Carnecky wrote:
nifty features, like per-app volume, transparent sink switching etc, some of which are impossible to emulate through the alsa pulse plugin.
Which features can't be used through the alsa->pulse plugin? And is there any technical reason for that or just missing functionality in that plugin?
Jan
Jan Zerebecki wrote:
On Fri, Feb 22, 2008 at 01:50:09AM +0100, Tomas Carnecky wrote:
nifty features, like per-app volume, transparent sink switching etc, some of which are impossible to emulate through the alsa pulse plugin.
Which features can't be used through the alsa->pulse plugin? And is there any technical reason for that or just missing functionality in that plugin?
All wine apps are identified as 'ALSA plug-in [wine-preloader]' in the PA daemon, so you can't set per-app volume and sinks since all wine apps show up under the same name. That is a technical limitation of the alsa plugin and can't be fixed (well, unless the plugin does some /proc/self voodoo to extract the true name). However that does not make the plugin unusable, but per-app settings is a major functionality of PA, so it's kind of bad if that doesn't work. I have gotten winealsa to work with a patched alsa pulse plugin, but whether my patch will be accepted remains uncertain. There are some fundamental differences between ALSA and PA, for example ALSA uses frames and PA uses microseconds and I suspect there are rounding issues involved that make winealsa hang in certain situations. I'll need some help from the PA developers to fix that, but so far it's been quite difficult to get hold of them.
tom
On Sun, Feb 24, 2008 at 12:05:46PM +0100, Tomas Carnecky wrote:
All wine apps are identified as 'ALSA plug-in [wine-preloader]' in the PA daemon, so you can't set per-app volume and sinks since all wine apps show up under the same name. That is a technical limitation of the alsa plugin and can't be fixed (well, unless the plugin does some /proc/self voodoo to extract the true name). However that does not make the plugin unusable, but per-app settings is a major functionality of PA, so it's kind of bad if that doesn't work.
I'm not sure if /proc/self is the right way to implement this but in some way it should be made possible with the alsa->PA plugin.
(Why isn't the changed process name used, that is also shown by ps? Perhaps it should be implemented by using a environment variable and/or argument to the alsa->PA plugin, that would also allow the following feature?)
Does PA (when used "directly") also always use the original process name? I imagine I'm not the only one who would want to have a bit more configurability there (some processes with the same executable should probably not share the same settings and the other way around).
I have gotten winealsa to work with a patched alsa pulse plugin, but whether my patch will be accepted remains uncertain. There are some fundamental differences between ALSA and PA, for example ALSA uses frames and PA uses microseconds and I suspect there are rounding issues involved that make winealsa hang in certain situations. I'll need some help from the PA developers to fix that, but so far it's been quite difficult to get hold of them.
We should really get those things that are wrong in either winealsa or PA fixed. (Assuming the PA developers are interested...)
AFAIK bug #10942 and at least the part of bug #10910 about "Could not find 'PCM Playback Volume' element" are things that need fixing in winealsa.
Jan
Jan Zerebecki wrote:
On Sun, Feb 24, 2008 at 12:05:46PM +0100, Tomas Carnecky wrote:
All wine apps are identified as 'ALSA plug-in [wine-preloader]' in the PA daemon, so you can't set per-app volume and sinks since all wine apps show up under the same name. That is a technical limitation of the alsa plugin and can't be fixed (well, unless the plugin does some /proc/self voodoo to extract the true name). However that does not make the plugin unusable, but per-app settings is a major functionality of PA, so it's kind of bad if that doesn't work.
I'm not sure if /proc/self is the right way to implement this but in some way it should be made possible with the alsa->PA plugin.
(Why isn't the changed process name used, that is also shown by ps? Perhaps it should be implemented by using a environment variable and/or argument to the alsa->PA plugin, that would also allow the following feature?)
http://www.pulseaudio.org/browser/trunk/src/pulse/util.c#L160
Basically uses readlink("/proc/self/exe") and if that fails the falls back to prctl(PR_GET_NAME).
Does PA (when used "directly") also always use the original process name? I imagine I'm not the only one who would want to have a bit more configurability there (some processes with the same executable should probably not share the same settings and the other way around).
When a PA client connects to the daemon it can specify the context name (a name identifying the application) and each stream also has a name (the alsa pulse plugin sets that to "PCM Playback" for playback streams). Each client can choose its own name, the alsa pulse plugin extracts the name like described above, applications that use PA natively usually choose a fixed name: mplayer uses "MPlayer", netscape flash uses "Adobe Flash" etc.
I have gotten winealsa to work with a patched alsa pulse plugin, but whether my patch will be accepted remains uncertain. There are some fundamental differences between ALSA and PA, for example ALSA uses frames and PA uses microseconds and I suspect there are rounding issues involved that make winealsa hang in certain situations. I'll need some help from the PA developers to fix that, but so far it's been quite difficult to get hold of them.
We should really get those things that are wrong in either winealsa or PA fixed. (Assuming the PA developers are interested...)
AFAIK bug #10942 and at least the part of bug #10910 about "Could not find 'PCM Playback Volume' element" are things that need fixing in winealsa.
See http://www.pulseaudio.org/ticket/198 what the pulse devs think of that issue.
tom
-
Jan Zerebecki -
Stefan Dösinger -
Tomas Carnecky