PulseAudio as a sound output?
dlphilp at linux-sound.org
Mon Oct 8 07:43:30 CDT 2007
Maarten Lankhorst wrote:
>Damjan Jovanovic schreef:
>>Pulseaudio isn't "yet another sound server", it's a full-blown
>>replacement for all other sound servers. It mixes sound better than
>>alsa's dmix, it's a drop-in replacement for ESD, and it works even for
>>OSS applications using oss2pulse. Some of its interesting features
>>include per-application volume levels, RTP multicasts, the ability to
>>embed it within an application instead of running a separate server,
>>and a Windows port.
>>The reason it would be good for wine is because it (optionally) runs
>>in realtime (SCHED_RR) priority, and is designed for low-latency
>>playback. Even wine's latest alsa driver continuously stutters under
>>high CPU load (play back some music with foobar2000, while searching a
>That's not the fault of our audio driver, it is because of linux doing
>bad things with i/o scheduling. For whatever reason as soon as a wine
>blocks on i/o all other threads get cpu starved. This is not a wine bug,
>but a linux bug.
>I'm not in favor for yet another half supported sound system, I would
>rather have our own sound systems working better. Can't you just use
>forwarding from JACK or something?
I'm not a Wine devel, but I am closely allied with the Linux audio
community (yes, there is such a thing) and I use Wine frequently for
running Windows ASIO-based music and sound apps. I use Robert Reif's
wineasio driver, which basically does what Maarten would like to see.
IMO the Wine/Linux audio problem stems from the very different primary
uses of sound: normal audio/video playback (CD, DVD, streaming A/V,
etc), games, and desktop/studio audio production. Each of these uses has
its own needs and expectations. Normal playback and game use wants
surround and 3D sound support, along with the ability to not interfere
with other audio processes (software mixing). Pro-audio usage needs
low-latency and zero dropouts.
JACK would seem to be the best-case solution (wineasio depends on it),
but I fear it's overkill for the normal user. Also, it's not a default
feature in most Linux distros (excepting of course the
multimedia-optimized ones such as 64 Studio, JAD, Planet CCRMA, Musix,
dynebolic, etc). The esd and artsd servers are not designed for
low-latency and other pro-audio specs, so while they'll work for normal
use they are unsuitable for serious production. So yes, there's a
problem. Can there be a one-size-fits-all solution ?
Well, first I'd suggest simply supporting ALSA as thoroughly as
necessary or possible. It is the default kernel sound system, Wine may
as well incorporate it as well as it can. Supporting the deprecated OSS
API might be a good idea too, through ALSA's OSS-compatibility layer. As
one devel noted, it may be a good idea to forego further development of
things like the NAS and ESD servers until a more solid basis exists for
I also urge any Wine audio development to stay in touch with general
developments in Linux audio. The wineasio driver is already good enough
to draw some Windows users into the fold. That driver gives them
low-latency close to native performance (i.e. with ASIO), and a variety
of Windows sound and music apps can now be run in a production capacity.
The issue of VST support is a show-stopper for many musicians who would
like to switch platforms. For a while, the FST project provided a nice
bridge that allowed running VST/VSTi plugins as standalone programs, but
a long-standing X-related bug (since at least the 0.9.3x series) has
gutted FST's capability. So at this time, if a user wants to use VST
plugs he can either use FST with an older Wine, or he can use a new
version with the wineasio driver. Btw, both solutions depend on JACK.
A bit of a ramble, but I hope I've made my point. Sound support in Wine
is an important aspect of its development, and many users are currently
thwarted in their attempts to leave Windows simply because their
favorite sound-apps can't be run in Wine. I don't expect to see Cubase
or Logic running under the system any time soon, but it would be a cool
thing to look forward to eventually happening. :)
More information about the wine-devel