This is pretty dissapointing, I'd expect any Pulse Audio developer to be better informed.
When I was watching Freenode's Arch Linux channel, someone mentioned that OSS4 would probably replace ALSA one day. I eventually took a look at it, and was suprised at how good its driver support was. hda_intel device's mic ports rarely worked out of the box with ALSA for me, but were flawless in OSS4. OSS4 is a very nice system, although I wish more applications supported 24 bit audio with it, and that it had a nicer build system. I am building an Arch Linux fork called Icadyptes, and OSS4 is now the exclusive audio system :-). It does not even have ALSA modules anywhere in the repository; not much reason to have them in my opinion. Cheers, Teran (sega01) PS: It would be nice if ossplay had its stdin support documented (currently not in the man pages or ossplay -h). On Fri, Sep 26, 2008 at 04:52, Lyvim Xaphir <[EMAIL PROTECTED]> wrote: > This shit really, really really pisses me off. > > LX > > > > On Wed, 2008-09-24 at 21:07 -0700, Dev Mazumdar wrote: >> Yair K. wrote: >> > On Thursday 25 September 2008 01:02:31 SeaJey wrote: >> >> Source: http://0pointer.de/blog/projects/guide-to-sound-apis >> >> Quote: >> >> <skip> >> >> OSS >> >> The Open Sound System is a low-level PCM API supported by a variety of >> >> Unixes including Linux. It started out as the standard Linux audio system >> >> and >> >> is supported on current Linux kernels in the API version 3 as OSS3. OSS3 >> >> is >> >> considered obsolete and has been fully replaced by ALSA. A successor to >> >> OSS3 >> >> called OSS4 is available but plays virtually no role on Linux and is not >> >> supported in standard kernels or by any of the relevant distributions. >> >> The OSS >> >> API is very low-level, based around direct kernel interfacing using >> >> ioctl()s. >> >> It it is hence awkward to use and can practically not be virtualized for >> >> usage >> >> on non-kernel audio systems like sound servers (such as PulseAudio) or >> >> userspace sound drivers (such as Bluetooth or FireWire audio). OSS3's >> >> timing >> >> model cannot properly be mapped to software sound servers at all, and is >> >> also >> >> problematic on non-PCI hardware such as USB audio. Also, OSS does not do >> >> sample type conversion, remapping of resampling if necessary. This means >> >> that >> >> clients that properly want to support OSS need to include a complete set >> >> of >> >> converters/remappers/resamplers for the case when the hardware does not >> >> natively support the requested sampling parameters. With modern sound >> >> cards it >> >> is very common to support only S32LE samples at 48Khz and nothing else. >> >> If an >> >> OSS-client assumes it can always play back S16LE samples at 44.1Khz it >> >> will >> >> thus fail. OSS3 is portable to other Unix-like systems, various >> >> differences >> >> however apply. OSS also doesn't support surround sound and other >> >> functionality >> >> of modern sounds systems properly. OSS should be considered obsolete and >> >> not >> >> be used in new applications. ALSA and PulseAudio have limited >> >> LD_PRELOAD-based >> >> compatibility with OSS. >> >> >> >> Are the things so bad or this is kind of rant? >> > >> > It's pretty inaccurate FUD (From the URL address - it's Pulseaudio's >> > author, right? I'd have expected him to know better). He's basically >> > judging OSS per the old OSS/Free drivers, which is like 5 years ago, and >> > even that he does wrong. >> > First, *all* current implementations/emulations of OSSv3 do sample >> > conversion. It's not even a property defined by the API but by the >> > underlying drivers. >> > Second, even OSSv3 supported surround, USB cards, etc. >> > Third, arguing that "it cannot be virtualized" is disproven by the amount >> > of emulations and alternative implementations existing out there and >> > working in practice. (The main difficulty is mmap() API, which is very >> > rarely used anyway, and even that can be done with, say, oss2pulse). >> > Fourth, complaining about OSS API being awkward, is... well, awkward when >> > you compare it to ALSA API, if you could compare it, since most ALSA API >> > isn't documented. >> > It's kinda funny he advocates using ALSA API (not in the quoted part >> > above, but last time I read his blog he suggested it). Actual ALSA devs >> > advocate against it, but using a sound library with multiple backends[1]. >> > >> > [1] e.g. http://www.archivum.info/linux.kernel/2006-01/msg02687.html >> > >> > P.S. Most modern soundcards I've seen do "S16LE" and nothing else, >> > unfortunately. >> > _______________________________________________ >> > oss-devel mailing list >> > oss-devel@mailman.opensound.com >> > http://mailman.opensound.com/mailman/listinfo/oss-devel >> > >> >> >> Hi, >> >> I've already sent Lennart a note.....here's his response. >> >> The biggest piece of BS: OSS also doesn't support surround sound and >> other functionality of modern sounds systems properly. ... >> >> regards >> Dev >> >> -------- Original Message -------- >> Subject: Re: [alsa-devel] Guide to Linux Sound APIs >> Date: Thu, 25 Sep 2008 02:35:21 +0200 >> From: Lennart Poettering <[EMAIL PROTECTED]> >> Organization: Red Hat, Inc. >> To: Dev Mazumdar <[EMAIL PROTECTED]> >> References: <[EMAIL PROTECTED]> >> <[EMAIL PROTECTED]> >> >> On Wed, 24.09.08 16:05, Dev Mazumdar ([EMAIL PROTECTED]) wrote: >> >> > How did you decide for all the Linux community that Open Sound System >> > should not be used for any new programs?. >> >> I did not "decide" anything. I just wrote up a guide that gives >> recommendations. >> >> I gave quite a few reasons why I think noone should write new >> Linux applications for the OSS API: >> >> <snip> >> ... OSS3 is considered obsolete and has been fully replaced by ALSA. A >> successor to OSS3 called OSS4 is available but plays virtually no role >> on Linux and is not supported in standard kernels or by any of the >> relevant distributions. The OSS API is very low-level, based around >> direct kernel interfacing using ioctl()s. It it is hence awkward to >> use and can practically not be virtualized for usage on non-kernel >> audio systems like sound servers (such as PulseAudio) or user-space >> sound drivers (such as Bluetooth or FireWire audio). OSS3's timing >> model cannot properly be mapped to software sound servers at all, and >> is also problematic on non-PCI hardware such as USB audio. Also, OSS >> does not do sample type conversion, remapping or resampling if >> necessary. This means that clients that properly want to support OSS >> need to include a complete set of converters/remappers/resamplers for >> the case when the hardware does not natively support the requested >> sampling parameters. With modern sound cards it is very common to >> support only S32LE samples at 48KHz and nothing else. If an OSS client >> assumes it can always play back S16LE samples at 44.1KHz it will thus >> fail. OSS3 is portable to other Unix-like systems, various differences >> however apply. OSS also doesn't support surround sound and other >> functionality of modern sounds systems properly. ... >> </snip> >> >> Sure, some of the issues pointed out here may have been fixed in >> OSS4. But OSS4 is irrelevant on Linux. Also we don't need two APIs >> that have the same purposes. That's why this guide recommends ALSA and >> not OSS. >> >> > We have been telling our customers quite the contrary to go with >> GStreamer >> > rather than use Pulse Audio. >> >> You seem to confuse things here. GStreamer and PulseAudio solve >> completely different problems and have almost nothing in common. It's >> like recommending to go with a window instead of a dog. ;-) >> >> > I think you may have completely underestimated the practicality and the >> > robustness of Open Sound. >> >> Hehe, that doesn't change the fact that OSS3 is obsolete and OSS4 plays >> no role on Linux and the API is generally questionnable. >> >> Lennart >> >> -- >> Lennart Poettering Red Hat, Inc. >> lennart [at] poettering [dot] net ICQ# 11060553 >> http://0pointer.net/lennart/ GnuPG 0x1A015CC4 >> >> > > _______________________________________________ > oss-devel mailing list > oss-devel@mailman.opensound.com > http://mailman.opensound.com/mailman/listinfo/oss-devel > _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
