Subject: Re: [linux-audio-dev] efficient non-blocking writes to /dev/dsp
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Apr 03 2001 - 23:15:53 EEST
In message <3ACA1FE4.B8E4EBE8_AT_pp.htv.fi>you write:
>Paul Davis wrote:
>>
>> if you've bothered to upgrade to 2.4.2+lowish, what on earth are you
>> still doing using the OSS API ?
>
>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
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 16:00:02 EEST