From alsa-devel-owner@alsa.jcu.cz  Fri Mar 13 21:38:13 1998
Received: from entry.jcu.cz (perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id VAA15930;
	Fri, 13 Mar 1998 21:38:11 +0100
Date: Fri, 13 Mar 1998 21:38:11 +0100 (MET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Thomas Sailer <sailer@ife.ee.ethz.ch>
cc: alsa-devel@jcu.cz
Subject: Re: driver 0.0.6 & library 0.0.1
In-Reply-To: <35096B06.6EF4@ife.ee.ethz.ch>
Message-ID: <Pine.LNX.3.96.980313183946.16116A-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Fri, 13 Mar 1998, Thomas Sailer wrote:

> 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).

What about this:

kernel -> general sound multiplexer -> PCM multiplexer

PCM multiplexer -> midlevel ISA PCM -> lowlevel code
PCM multiplexer -> midlevel PCI PCM -> lowlevel code
PCM multiplexer -> lowlevel code [-> library]

Above diagram covers all. I'm not much sure if PCI midlevel will be
different from ISA midlevel, but we should create some backdoor for far
future...

> 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.

I agree..

> 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.

Note that driver at current state cann't use only ISA DMAable memory as
OSS/Lite does. I tried make midlevel PCM code universal - all specific code
which operates with samples is called indirectly using callbacks.

This leaves space to lowlevel driver to these things:

1) where is final sample placed
2) sample should be converted before is placed to memory used by hardware
3) size of buffer should not be limited to maximum ISA (or other bus) DMA
   buffer and should be placed anywhere (system DRAM, soundcard DRAM
   etc..)

And allows to midlevel codes (currently native pcm code & OSS/Lite
emulation code) share same lowlevel code.

Most limitations is given by API. I assume that most of code (to manage
fragments for example) will be (and probably must be) same for all
midlevel codes.

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

I don't know anything about PSS cards, but if these cards use only
polled mode thus this type of soundcards isn't very good for Linux
environment.

> 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

Indirect callback to midlevel code, but this is really problem if we will
have more midlevel codes with different data structures :-((((

> other kernel subsystems, it might be beneficial to
> use a separate kernel thread for these subsystems, but I dunno
> currently...
> 
> 
> Tom

					Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic





