PulseAudio as a sound output?

[Maarten Lankhorst]

Hello Dave,

Dave Phillips schreef:
> 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.
>   
Games do too, however it stays a compromise between low latency and a
risk of dropouts. The dropouts are caused by the kernel, you could
slightly tweak it, and get it down to ~70ms, but more isn't possible
without tweaking dmix to use 512 frames in a period instead of 1024, or
direct hardware access.
> 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.
>   
That's what I've been trying, I hope I succeeded. There are still some
problems with directsound, but there are few things left I can do about
those.
> 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.
>   
I have nothing against incorporating wineasio, as long as you can get
someone to maintain it once it's in, rather then let it slowly bitrot
away, but if wineasio and winejack do the same, it would make sense to
make 1 of the 2 go.
> 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.
>   
Have you considered filing a bug report, and do a regression test? It's
easy to do and would allow you to find the exact cause of the glitch,
and if it's obvious you could even fix it yourself.
> 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. :)
>   
I agree.

Cheers,
Maarten