[linux-audio-dev] Re: RFD: Audio Needs for Kernel 2.5+

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Re: RFD: Audio Needs for Kernel 2.5+
From: Scott McNab (sdm_AT_fractalgraphics.com.au)
Date: Tue Jun 20 2000 - 04:51:27 EEST


> ----------------------------------------------------------------------
> Right questions:
> Will we be using the ALSA API
> Will we be including ALSA drivers
>
> API:
> For the synth/midi stuff yes. The OSS API for synth stuff looked
> bad 3 years ago.
>
> I don't see the advantage of changing the dsp side API at all.
> I'd rather expand that for 5.1 and positional audio. I also have
> a worry about mmap() support now. Sound cards are getting stupider
> not brighter (in fact if we wait long enough they'll be stupid enough
> for OSS to support again at this rate)

These sort of comments really worry me. Especially coming from someone with such
a high influence as Alan. It shows a complete lack of understanding of the
limitations of the existing OSS audio API and the advantages of the ALSA driver
design.

Perhaps someone suitably qualified (Jaroslav?) should prepare a list of exactly
what is bad about the OSS API and what advantages are offered by adopting ALSA
in its entirety.

> The mixers Im still unsure about.

And so are we, judging from recent discussions on alsa-devel.

> CODE:
> Once we have the API sorted out (thats the important bit) then we can
> do a cleanup job over ALSA itself and start to import the drivers that
> are useful - first candidates are those that are immediately better
> or unique to ALSA, then if things work out I'd like to have a tree
> where there are no (or nearly no) OSS core based drivers by 2.6
> release date

A couple of years back I followed closely the development of the General Graphics
Interface (GGI) which was trying to do the same thing for graphics under Linux
as ALSA is does for sound. These guys had a great compact and extensible Kernel
Graphics Interface (KGI) layer for providing lowlevel access to video hardware
(much like alsa-driver) and a user-space driver layer to provide consistent access
to a great variety of different video cards supporting different levels of
hardware acceleration (just like alsa-lib).

When they pushed to get KGI included as the standard kernel-level graphics API
for Linux (as there wasn't one at the time) they received much resistence.
As a result, the kernel developers took the bits of KGI which they wanted
(ie. bits of device-specific code) and instead dodgeyed up their own 'graphics
interface API' which became what are now the Linux framebuffer device drivers.

The fb device drivers managed to meet only one of the problems that KGI solved
(ie. providinf a console device for architectures without graphics adaptors
with text modes) but totally failed on other counts, such as supporting a
consistent abstraction of hardware acceleration.

The result? Noone really uses the framebuffer device at all except if they are
using a non-Intel machine. The really stupid thing is that now they have had to
develop a separate Direct Rendering Interface (DRI) to address the inadequacies
of their hacked-together framebuffer API.

Had they done things properly in the first place (and made KGI the default graphics interface layer) the DRI changes would have been trivial to implement, if they
weren't already supported. Furthermore, XFree86/svgalib/OpenGUI/etc would only
need the one low-level driver interface (KGI), rather than having to carry the
baggage of code to handle the perculiarities of every graphics card on the planet.

Anyone else see the parallelism here?

Scott


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jun 20 2000 - 05:18:11 EEST