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
