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