PulseAudio as a sound output?

Dave Phillips 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
>>large PDF).
>>  
>>    
>>
>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?
>
Greetings,

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 
ALSA/OSS.

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. :)

Best regards,

Dave Phillips




More information about the wine-devel mailing list