<br><br><div class="gmail_quote">On Wed, Sep 30, 2009 at 12:51 AM, oiaohm <span dir="ltr">&lt;<a href="mailto:wineforum-user@winehq.org">wineforum-user@winehq.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Vitamin is right OliWarner.   Lot less applications work with Pulseaudio driver for wine than using   <a href="http://userweb.kernel.org/%7Etj/ossp/" target="_blank">http://userweb.kernel.org/~tj/ossp/</a> to send the wine oss driver up into Pulseaudio.   Basically there is no point to the pulseaudio driver since there are other ways to get better results.<br>

</blockquote><div><br>Correct me if they&#39;re not but the following statements appear to be true:<br><ul><li>ossp is a kernel level patch</li><li>It isn&#39;t included by default on popular distro kernels<br></li><li>Patching and rebuilding your kernel is harder than patching wine by several measures<br>

</li></ul> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Currently the codec support is the most critical thing for wine to get from Gstreamer.  This is number of applications working thing.  The developer working on the codec support has interest in developing a low level sound out for the simple issue.  If all sound is going threw Gstreamer it can manage it avoiding broken audio.<br>

</blockquote><div><br>This is clearly the best, next opportunity to have audio fixed once and for all on Wine. It&#39;s a pity the focus is on codecs but it&#39;s good to see there are napkin plans to develop it out.<br>
<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Personally I hate Pulseaudio.  To my mind resource management is the job of the Kernel.   X11 made this same mistake of managing resources in user space to stack so problems.  The kernel can enforce the only 1 management system that can not be bypassed.   What happens if something connects to audio out before pulseaudio yep no sound.  Pulseaudio design has the same flaw of all sound servers the bipass and screwed issue.<br>


</blockquote></div><br>Sound servers do a lot more than just relay sound to hardware. That&#39;s the point! Features and flexibility. There shouldn&#39;t a bypassing issue as all sound <i>should</i> be routed through them (that&#39;s the aim, after all). <br>

<br>Your argument is like saying cars are flawed because people can steal them from you. Of course that&#39;s not the intended purpose, just as it&#39;s not intended for other processes to hog the audio hardware.<br><br>
But I get it. Some people just plain don&#39;t like Pulseaudio. I didn&#39;t write it so I&#39;m not offended by it but <i>I</i> and <i>thousands</i> of other users use it, even if you don&#39;t or don&#39;t want to. Complaining about it here won&#39;t help as none of us here (afaik) are on the audio team of any big distribution.<br>