On Sun, Apr 06, 2008 at 05:41:05PM +0200, Stefan Dösinger wrote:
Am Sonntag, 6. April 2008 12:27:51 schrieb Jan Zerebecki:
Yes, more precicely it's about how the alsa->pulse plugin tries to identify different applications. It gets the real process name (the loader), not the one wine changed to. The plugin could use that, but it would also be nice if the plugin would take an optional argument to set the name explicitly like on can with the pulse api.
I don't see how the process name or a process identification is a proper primary key for sound clients. They should rather use the alsa primary buffers requested by the apps rather than the process identification. They could still use the process name as a description for the user interface, using anything not directly sound API related like PID, process name, ..., as the identifier for a sound client is broken IMHO.
It results in the behaviour that the user would expect. E.g. that one game you start retains the same settings everytime it creates a primary buffer (thus that it retains the settings on the next start) and the voice chat client also always retains it's separate setting.
I'd expect most pulse using applications use one identifier for their whole application (and the same one on each start).
There is nothing like that identifier in alsa and AFAIK neither in dsound/winmm.
Jan