Subject: Re: [linux-audio-dev] ALSA vs OSS/free
From: Jussi Laako (jussi.laako_AT_kolumbus.fi)
Date: Sat Mar 09 2002 - 17:22:29 EET
Paul Davis wrote:
>
> QNX too. :)))
True, I've used it, but it supports only 0.5 API.
> 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.
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. alsa-devel mailing list doesn't accept mails from me so I can't make
any questions there anymore.
OSS is simple, open, set speed, channels and format and that's it. Four
function calls.
> You can link statically.
Didn't work for me with Intel C++ compiler.
> 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... ;)
> 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.
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.
> 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.
Have you written any hardware drivers using RT-Linux or RT-AI? It's fun and
very low latency.
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").
> btw, IRIX doesn't follow the ideology you mention either. not that
> this says much?
Of course there are always strange variants.
- Jussi Laako
-- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at PGP keyservers
This archive was generated by hypermail 2b28 : Sat Mar 09 2002 - 17:16:01 EET