From alsa-devel-owner@alsa.jcu.cz  Fri Mar 13 18:22:11 1998
Received: from ife.ee.ethz.ch (ife-ife2.ee.ethz.ch [129.132.25.129])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id SAA05751;
	Fri, 13 Mar 1998 18:21:11 +0100
Received: from eldrich.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.24.203])
	by ife.ee.ethz.ch (8.8.5/8.8.5) with SMTP id SAA12194;
	Fri, 13 Mar 1998 18:21:10 +0100 (MET)
Message-ID: <35096B06.6EF4@ife.ee.ethz.ch>
Date: Fri, 13 Mar 1998 18:21:10 +0100
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
CC: perex@jcu.cz
Subject: Re: driver 0.0.6 & library 0.0.1
References: <Pine.LNX.3.96.980308225904.22324F-100000@entry.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Hi Jaroslav

Lately I looked at the driver v 0.0.6, the PCM part.
Here are some observations:

Currently, the call sequence for kernel calls (such as open,
write, ioctl, etc.) looks something like:

kernel -> general sound multiplexer -> midlevel pcm
driver (pcm.c) -> low level driver.

However, I think it would be better it was:

kernel -> general sound multiplexer -> low level driver ->
 midlevel pcm driver (pcm.c).

Because the low level driver has the most knowledge about the
hw, and should be able to control everything, even providing
its own midlevel driver if the supplied one does not fit
the particular HW. It might even well be that we need
multiple midlayers, eg. one for ISA, one for PCI etc.

This was originally what Linus suggested, I'll append his
mail at the end.

The reason why I'm saying this is that I have some plans
for drivers for "unusual" soundcards. I'm supposed to get
a PCI soundcard soon, so I don't want to limit the driver
to use ISA DMAable memory. Also, chips like the CS4610/11 would
be fairly castrated if they had to use the ISA scheme.

Another long standing project is a fullduplex no DMA no IRQ
driver for PSS cards.

Another issue is I'd like to get rid of the sound card
hw layer of soundmodem and hfmodem in the long range. For this
I'd need hooks for in kernel clients, but I'm still unsure about
how to best do it. Currently, the upper layer is called
from the interrupt handler. Depending on developments in
other kernel subsystems, it might be beneficial to
use a separate kernel thread for these subsystems, but I dunno
currently...


Tom


Here comes Linus' message:

From: Linus Torvalds <torvalds@transmeta.com>
To: Thomas Sailer <sailer@ife.ee.ethz.ch>
cc: alan@lxorguk.ukuu.org.uk, mec@shout.net, daniel@futurniture.se
Subject: Re: Sound...
Message-ID: <Pine.LNX.3.95.980112105645.574C-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2656

On Mon, 12 Jan 1998, Thomas Sailer wrote:
>
> Linus Torvalds wrote:
> 
> > In particular, I'd prefer to see the different sound-drivers be a lot more
> > independent - obviously with the same interfaces, but _not_ necessarily
> > with any common entry-points at all.
> 
> Hm - but at least all ISA DMA cards share the ISA DMA code,
> and that is quite some code and can be shared :-)

Note that I'm not saying that they shouldn't share code, but I'm saying
they should be _independent_. 

Right now it looks something like this:

                +-----------------------+
                |       kernel          |
                +-----------------------+
                            |
                +-----------------------+
                |  common sound switch  |
                +-----------------------+
                    |               |
                +-------+       +-------+
                |  #1   |       |  #2   |
                +-------+       +-------+

(switch "common sound switch" and "mid-level SCSI layer" for my other
argument with the SCSI stuff, which I also don't like for the same
reason). It _should_ be:

                +-----------------------+
                |       kernel          |
                +-----------------------+
                    |               |
                +-------+       +-------+
                |  #1   |       |  #2   |
                +-------+       +-------+
                    |               |
                +-----------------------+
                |   generic _library_   |
                +-----------------------+

The difference is one of who controls whom. The _reason_ the second one is
better is because it is more generic: it contains rougly the same amount
of code, but it allows the followign setup, for example:

                +---------------------------------------+
                |       kernel                          |
                +---------------------------------------+
                    |               |              |
                +-------+       +-------+       +-------+
                |  #1   |       |  #2   |       |  #3   |
                +-------+       +-------+       |       |
                    |               |           +-------+
                +-----------------------+
                |   generic _library_   |
                +-----------------------+

Imagine that sound card #3 is _so_ different from normal sound-cards that
the library doesn't really suit it.. So it doesn't use it. The same isn't
possible if you have the common parts controlling the low-level parts.

> I've finally come to senses and found out that the mmap interface
> of the sound driver is harmful (after promoting it for a year or
> so and modifying several apps to use it... hm.). It's inherently
> bound to ISA DMA and excluding any more intelligent controllers
> (that do scatter gather eg.) which are at least announced
> (Crystal Semi (now Cirrus)). It imposes a unnecessarily complex
> logic into the sound driver. Therefore I've decided to not
> implement it. But since there are apps using it, I'm playing
> around with an emulation of said interface (which can be
> CONFIG'd away) using the read/write semantics.

We must _not_ break quake etc, so a pretty perfect emulation layer is
definitely necessary. 

                Linus

