Subject: Re: [linux-audio-dev] ALSA vs OSS/free
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Mar 09 2002 - 19:18:34 EET
>> actually, its easier. it just isn't documented to make it seem that
>> way. the major benefits are that no device-specific hacks are needed
>> and format conversion is handled by alsa-lib. there are others. i
>
>OSS does format conversions. And also does samplerate conversion and
>software mixing for output.
but linus has announced that they want such code removed from the
kernel. only the pending arrival of ALSA has stopped this from happening.
OSS does not do s/w mixing for any devices that i know of. it supports
multi-open, just like ALSA, for all h/w that supports it, where the
means of doing so has been described by the h/w maker.
>I haven't been able to get 8-channel interleaved MSB aligned 24-bit input in
>32-bit words without libasound crashing to some mysterious internal error
>(plughw device), soundcard is Delta1010. No problem getting such format from
>OSS.
OSS has ZERO support for non-interleaved cards. there's no way to even
express the idea of it in OSS. is this some kind of competition?
>alsa-devel mailing list doesn't accept mails from me so I can't make
>any questions there anymore.
you're probably on a sourceforge dialup blacklist. it happened to me a
few weeks ago. i checked out why it was happening. sf.net won't accept
mail from IP addresses that have been determined to be used for dialup
clients. it has be routed through a static IP address that is known
not to be an open relay. i simply changed my sendmail.cf file to relay
via my ISP's mail server, and it worked again.
complain to sf.net if you think this policy is wrong - they've decided
to do it to try to limit the amount of spam being sent to the
thousands of mailing lists they host.
>OSS is simple, open, set speed, channels and format and that's it. Four
>function calls.
Four function calls on basic hardware. OSS is incapable of supporting
certain configurations. Its not just hard, its impossible.
In ALSA, it requires more. Thats because we don't want the cryptic
(and in most implementations of OSS, actually buggy) encoding of
channel format, for example. So yes, there are lots more function
calls so that you can set up the hardware and software parameters. But
if you just want to, it can be reduced to:
snd_pcm_open
snd_pcm_hw_params_alloc
snd_pcm_hw_params_set_speed
snd_pcm_hw_params_set_format
snd_pcm_hw_params_set_channels
snd_pcm_hw_params
snd_pcm_prepare
snd_pcm_start
...
snd_pcm_stop
snd_pcm_close
of course, if you want to find out how many channels the device has,
OSS can't help you (except by returning -EINVAL to an attempt to set
it). if you want to change when the kernel will wake up your process
thats sleeping on poll or select, OSS can't help you. if you want
control what the driver does if there is an xrun, OSS can't help
you. and if you want to control standard digital audio controls, like
clock source or IEC958 configuration, OSS can't help with that either
unless you want to write code specific for each different h/w device.
the point of an API is to make the easy things as easy as possible
while making the hard things possible. OSS makes the easy things very
easy, but doesn't allow the hard things at all. ALSA makes the easy
things easy, and allows for all the hard things that anyone has
brought up so far.
>> You can link statically.
>
>Didn't work for me with Intel C++ compiler.
Then why don't you fix up your email routing and join alsa-devel to
tell us about your experiences and maybe we can fix it.
>> you are welcome to program using /dev/snd/whatever. the API is the
>> standard Unix API, featuring open/read/write/close/ioctl/mmap. nothing
>
>This is not too documented way... ;)
Not much of ALSA is documented at this time. Feel free to volunteer to
help with the effort.
>> but in the case of audio, linus, alan and others have made it clear
>> (and most of us agree with them) that they do not accept the idea that
>> format conversion, channel mapping, {de,re}interleaving, device
>> sharing (*not* h/w multiplexing) etc. should live in the kernel if at
>> all possible. therefore, there are really useful aspects of an audio
>> API that under Linux *cannot* live in the kernel. where do *you* think
>> they should be?
>
>They _should_ be in kernel, as SCSI and similar layers are. But I don't
>think format conversions are necessary at all.
So where do you think interleaving and deinterleaving should be? How
about support for floating point format? What about handling of
multiple process access to the same device? What about support for
implementing "subset" devices (e.g. 12 stereo devices mapped to a 24
channel card)? Should they be in the kernel?
>My opinion is that we should have more microkernel like kernel and drivers
>running in protected memory space as in QNX. Drivers would communicate using
>message queues (as defined by POSIX 1003.1b and IEEE Std 1003.1-2001, mq_*
>functions). Take a look at QNX, Lynx or similar RT-OS architecture. That way
>drivers could have priorities with event priority inheritance and message
>priorities.
OK, so you want to rewrite Linux. That has nothing to do with ALSA.
>> the convention of accessing an inode that directly talks to a driver
>> is what stops OSS apps from being used flexibly, since nothing can
>> interpose between the app and the device without using LD_PRELOAD (gack!)
>
>Create kernel module which gets it's input from device driver X and
>implements same interface to outside world via device Y. All data passing
>would be done using event callbacks. Like RT-Linux FIFO handler functions.
>So no CPU time is used until there is data to handle. It would be easy to
>chain these, think about linked list of callbacks.
as erik mentioned, user-space device drivers appear to be coming to
linux bit by bit. we don't know enough about them yet to really
understand how good of an idea they are at this point.
>Have you written any hardware drivers using RT-Linux or RT-AI? It's fun and
>very low latency.
I spend too much of my time working on Linux device drivers to be
wasting any more on drivers for an operating system that almost nobody
will use. Sorry.
>ASIO2 is something in between, it's the only thing I like about Windows.
>Let's just hope that Steinberg & co start making also Linux ASIO2 drivers
>and API. We could just have something like ASIOOpen("/dev/dsp0").
Abramo and I once sketched out how to write ASIO on top of alsa-lib.
However, JACK is even simpler than ASIO, and it already exists (insert
ob. rant about CVS access here).
--p
This archive was generated by hypermail 2b28 : Sat Mar 09 2002 - 19:08:26 EET