Fate of PulseAudio in WINE

Arthur Taylor theycallhimart at gmail.com
Tue Jun 16 05:33:12 CDT 2009


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