> Okay, not dead, just not packaged as a default in any Linux distribution > that i can think of, and in particular, not supported in most modern audio > applications written for linux. Obviously there are exceptions, that i > should have considered before i posted that, like Unix systems that are > using OSS. but OSS is going to eventually be a dead/obsolete project in > Linux ~ i think that's pretty hard to argue. > > I haven't used OSS in years. http://www.opensound.com/ Then check out OSS4. It combines the a lower-level/low-latency/direct-access portions of ALSA (driver based) with the scheduling/sampling/mixing/per-application high-level interface of sound servers like PulseAudio - all *without* the overhead of a userspace sound server. The OSS 3+ API is also a supported sound system on the BSDs and Solaris which allows for Wine portability. Again, OSS is certainly not dead; OSS4 supports most modern sound hardware and exposes their features without the need for janky, problematic sound servers. Using OSS4 on a modern distribution and killing PulseAudio allows modern hardware to work with Wine on Linux. PulseAudio simply doesn't work sometimes. Once nicety (and problem) with PulseAudio is that applications support OSS or ALSA don't need to be rewritten or even recompiled. ALSA or older OSS3 applications simply make calls to their respective sound systems, which are caught by PA then sent back to ALSA-backed hardware. That layer of abstraction, particularly for the ALSA-PulseAudio-ALSA calls, adds overhead and latency. This is probably acceptable with most desktop applications like browsers or simple sound and video players, but kills sound performance where it counts, namely in Wine while attempting to run resource-intensive applications like games and professional sound apps. A low-latency sound server like JACK (including ASIO applications in Wine) sitting directly on top of ALSA/OSS is much more desirable than PulseAudio support. This has all been debated before; until PulseAudio provides a low-latency server and/or allows a *reliable* way (pasuspender not included) to pass calls directly through to hardware, it's just not a viable option for Wine. -r
