Fate of PulseAudio in WINE

Roderick Colenbrander thunderbird2k at gmail.com
Tue Jun 16 06:14:58 CDT 2009


Hi Arthur,

I would recommend you to also read this thread:
http://www.winehq.org/pipermail/wine-devel/2009-June/076102.html

As mentioned before we would like not to have a pulse audio driver if
it isn't needed at all. Some suggestions have been made to use some
pulseaudio rules of thumb in our winealsa code to improve the
situation. This is likely not doable for some of the stuff like mmap
which is needed for direct card access (directsound requires that) but
fixes in that area could already improve winealsa <-> pulse
interaction a lot. Remaining issues might be solvable in cooperation
with the pulse developers.

I think a lot of issues can already be fixed without requiring a new driver.

Regards,
Roderick Colenbrander


On Tue, Jun 16, 2009 at 12:33 PM, Arthur Taylor<theycallhimart at gmail.com> wrote:
> Recent activity in http://bugs.winehq.org/show_bug.cgi?id=10495 has
> caused some issues. This is also a response to
> http://www.winehq.org/pipermail/wine-devel/2009-April/074666.html
>
> First the background. WinePulse has been an attempt to write a winmm
> backend for pulseaudio for wine. Currently the primary audio system
> used by wine is through winmm.dll which sends messages to a backend
> which basically represents the MS waveOut and waveIn APIs.
>
> WaveOut works through wavehdrs, a single-linked list structure which
> contains a data field pointing at a buffer. Applications feed wavehdrs
> via waveOutWrite and receive a message when they have finished being
> played. wavehdrs can be formed into loops using flags. This is all
> simple enough except for how variable it is. Applications usually
> allocate a set size of wavehdrs and then use them circularly.
> Applications usually use when a wavehdr is returned for timing
> purposes rather than waveOutGetPosition. The number of wavehdrs and
> their sizes is entirely up to the application.
>
> There are two common problems with audio drivers implementing this
> system. The first is drivers which return a wavehdr as soon as it is
> written to output (waveesd.dr for example) as it will cause timing
> issues for applications when large batches of wavehdrs are returned at
> once. The second problem is when a windows application makes a smaller
> buffer of wavehdrs than the backend provides. In this case wavehdrs
> are not returned because they have not been played, and no more data
> can be written to fill the buffer because all the wavehdrs are waiting
> to be returned from the playback that is stalled. This can happen with
> alsa on top of plugins. If the buffered wavehdrs and playback buffer
> are very close in size sometimes the audio stutters by, oscillating to
> and from underrun and playback.
>
> Winepulse attempts to overcome these problems. It returns wavehdrs
> accurately and avoids stalls by modifying the pulseaudio server buffer
> size. In tests it works consistently.
>
> Most of the people I've had contact with have been positive toward
> development of such a backend. That said, the response from wine
> developers has been overwhelmingly negative. I can understand the
> desire for only clean and maintainable code to be considered for
> submissions. However, often it appears that the rejection is wholly
> philosophical rather than logical. Continual reports of problems are
> always contributed to silly users who are not using ALSA on top of
> direct hardware. I do not dislike either ALSA nor winealsa.drv, but I
> do reject this skepticism toward a world of Linux audio beyond SB-16
> style "direct hardware."
>
> The arguments that PulseAudio adds latency or is not suitable for
> professional audio are not relevant to the issue of whether or not a
> pulseaudio backend for wine should be added. The _addition_ of said
> backend _enables_ audio in wine for those who _choose_ to use
> pulseaudio. I can't imagine stopping pulseaudio just so I can listen
> to music through foobar2000, as that would stop all my voice chats,
> notification sounds, and other native audio, etc. For those whom
> pulseaudio is not appropriate, the other backends would still exist
> and pulseaudio can either be disabled temporarily via pasuspender, not
> started or not installed.
>
> That said, latency in pulseaudio is managed and through the winepulse
> patch exposed to the windows application. The daemon is usually run
> with realtime priority and will use data buffers if the requesting
> application locks temporarily, allowing less worry with recording.
>
> The method of audio playback and capture through waveOut and waveIn
> are quite broken. Even if winealsa uses the "safe ALSA api subset" it
> means that the poor and varied behaviours are translated to poor and
> varied alsa calls (DSound HEL is an exception here.) The winepulse
> patch attempts to overcome these issues by buffering sanely while
> trying to keep applications happy in a _consistant_ way.
>
> It is true that currently whitespace is an issue with the patches in
> the bug report. I will work to resolve this. The file was (supposed to
> be) indented using 4 spaces as this was the convention in all the
> other audio backends.
>
> Frankly, calling the code a search and replace from ALSA to PULSE is
> insulting. If this is true then it is therefore true that winealsa was
> a search and replace from OSS to ALSA. Almost all the wine audio
> backends share a common ancestor. The latest patch does not contain
> comment out code. There has been no *useful assistance* from wine
> developers (re "No Fucking Way"). As for which parts of the code
> aren't wine-64 ready, could you please expand?
>
> A detailed, constructive response with a clear vision for where the
> future of audio in wine lies would be appreciated.
>
> Thanks
> --
> Arthur Taylor
> art at ified.ca
> theycallhimart at gmail.com
>
>
>



More information about the wine-devel mailing list