From alsa-devel-owner@alsa.jcu.cz  Wed Apr  1 19:46: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 TAA19815
	for <alsa-devel@jcu.cz>; Wed, 1 Apr 1998 19:46:04 +0200
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 TAA15472
	for <alsa-devel@jcu.cz>; Wed, 1 Apr 1998 19:46:03 +0200 (MET DST)
Message-ID: <35227D5A.63D4@ife.ee.ethz.ch>
Date: Wed, 01 Apr 1998 19:46:02 +0200
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
Subject: Re: ALSA 0.0.7
References: <Pine.LNX.3.96.980401133848.13563A-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

> Fine. I don't know how much ESS ES1868 chip differ from 1688 version. I
> requested documentation from ESS Technology, but I didn't get any answer
> yet.

Don't know much about it either, but the main difference seems
to be that the former can now do fullduplex (but I think as
hackish as SB4).

> Maybe the best solution will be some sound configuration manager which
> will be called directly from driver (same way as kmod in 2.1.90+ calls
> modprobe). This manager will look and event type (startup for example) and
> run next utility (for example command line mixer for load default
> volumes).

There was some discussions about this lately on lk. kerneld
had the ability to store persistent data, but it got replaced lately
by kmod, which doesn't offer this capability. People suggested
to extend insmod to support module persistent data (this is not
only a sound problem, it's generic). 

Another question:
Alsadriver has several routines that can be called with parameters
in userspace or kernelspace. These routines take an extra
parameter to specify where to fetch the parameters (the SP_USER etc.
constants). Another possibility would be to always consider
data comming from userspace in the respective procedures,
and then encapsulate kernel space callers with set_fs/get_fs...
What were the design issues leading to the current design?

Another thing: I wanted to integrate my es1370 driver into alsa,
but haven't quite understood how to do it, can somebody shed
some light on it?

The main differences are: 
- it's PCI: trivial detection code (just enumerate devices
  and look for a specific vendor and device ID)
- It uses a ring buffer, just like ISADMA, but the buffer
  may be located anywhere in 32bit space, and start address
  pointer and length must be divisible by 8.
- It has one stereo ADC and two stereo DAC's, with somewhat
  hackish 4 channel mode.

Tom

