Hannu Savolainen <[EMAIL PROTECTED]> writes: > [...] > The whole "OSS is depracated" issue is just marketing propaganda used > to enforce application developers to jump to the ALSA API. Without this > developers would stick with OSS which is several magnitudes easier API > to use.
"Marketing propaganda?" 4Front Technologies is a company that engages in the sale of software for profit. 4Front Technologies therefore requires and presumably has a "market", people who pay them for their products. I don't think the same situation exists for those who develop ALSA. > OSS and ALSA are very different APIs. OSS is designed for professional > software developers who should get their job done within tight > schedules. For this reason it has strong device abstraction. Everything > that could be automated has been automated. ALSA in turn is designed for > hackers (in the 1st place) who like to tweak every possible detail of > the hardware. This means there is practically no device abstraction and > the application should be more or less aware of the capabilities of the > hardware. Which API works better depends on the nature of the > application. This decision should not be driven by some political issues > as today. So you say: OSS: professional software developers ALSO: hackers How do others feel about this issue. Here is an example from past discussion: From: Paul Davis <[EMAIL PROTECTED]> Date: Tue, 03 Apr 2001 16:15:53 -0400 To: LAD <linux-audio-dev@ginette.musique.umontreal.ca> Subject: Re: [linux-audio-dev] efficient non-blocking writes to /dev/dsp Message-Id: <[EMAIL PROTECTED]> In message <[EMAIL PROTECTED]>you write: > >I would like to know what's wrong with OSS API? its impossible to use it in an efficient hardware-independent fashion, because it has no concept of noninterleaved data streams. every time you want to add a new concept to it, such as changing the sample clock sync source, it can only be done via a new ioctl, which is rarely done in a h/w independent fashion but instead as a card-specific hack. the direct use of system calls means that its impossible to do the "grunt" work of, say, resampling or sample bitwidth changes in user space - this is all forced into the kernel. the system call-based API also prevents the interposition of additional layers to provide abstraction: the alsa-oss library, which is coming along very nicely as a way to get *full* ALSA functionality even when using /dev/dsp (rather than just OSS functionality via "emulation"), can only work by using the LD_PRELOAD hack. there's no way to "bind" physical connectors to channels in the OSS model: every OSS-based multichannel driver so far has allowed wierd things like "well, this time when i asked for 10 channels, I got channels 1-10, but the last time, it was 2-12". the kernel code has no interesting "midlevel" layer, forcing many drivers to either offer limited functionality or duplicate code from other drivers. need i go on ? basically, the OSS API is based on h/w models from the SB16 era; ALSA has successfully incorporated lots of lessons from devices like the Hammerfall, the ice1712-based devices and others. --p [...] > My message is that if you prefer OSS over ALSA then there is no need to > convert the code. OSS has been in the shadows during past couple of > years. However it will be back, We are working on an OSS version that > makes it possible to ALSA and OSS to co-exist. Probably, the widespread adoption of ALSA by the linux community gave you no choice but to develop such a version of OSS, no? Oh, and you mis-spelled "4Front Technologies"
