While PulseAudio can work through ALSA, it makes you lose the finer grains of control over audio when it is sent through ALSA to PulseAudio. It is also redundant in most cases, since PulseAudio generally will be connected to localhost to ALSA on localhost, so it is not very smart to rely on winealsa to connect to PulseAudio. the wineesd component could be replaced with a winepulse component (just made up the name, winepulse) that would support the finer grains of control in the audio server. Stuff like the application based mixer could be handled through winepulse and allow Wine to control only its own audio stream. That way, there isn't a conflict between audio streams to send to audio output. Sending audio output through ALSA/OSS to any audio server is basically redundant and pointless. Sending to the Audio Server to ALSA/OSS is better.
<br><br><div><span class="gmail_quote">On 10/9/07, <b class="gmail_sendername">Jan Zerebecki</b> <<a href="mailto:jan.wine@zerebecki.de">jan.wine@zerebecki.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I agree that wineoss needs to remain.<br><br>I don't remember anymore if there was still some reason for<br>keeping wineesd.<br><br>Both jack and pulseaudio can provide alsa support for<br>applications. So in principle there is no reason for direct
<br>support in wine for either of them.<br><br>We might be able to get trough with also removing winejack and<br>winenas. winejack could be replaced with either wineasio (which<br>uses jack directly) or with winealsa -> jacks alsa plugin. The
<br>main use case for winenas is network audio in a thin client<br>environment which I assume is also supported by pulseaudio where<br>we again can use winealsa -> pulseaudios alsa plugin.<br><br><br>Jan<br><br><br></blockquote>
</div><br>