From alsa-devel-owner@alsa.jcu.cz  Thu Apr  2 12:22:58 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 MAA09678;
	Thu, 2 Apr 1998 12:22:24 +0200
Date: Thu, 2 Apr 1998 12:22:23 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Thomas Sailer <sailer@ife.ee.ethz.ch>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: ALSA 0.0.7
In-Reply-To: <35227D5A.63D4@ife.ee.ethz.ch>
Message-ID: <Pine.LNX.3.96.980402115035.24388D-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 Wed, 1 Apr 1998, Thomas Sailer wrote:

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

OK. My question is now if is good start work on sound manager
program/interface or wait for new insmod. Persistant data should solve
problems with mixer default values, but I think that for example download
of some firmware code should be done from some program from user space.

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

Interresant idea and probably more clean. I'm starting to recode all
affected routines.

> What were the design issues leading to the current design?

Idea with space identifiers (and most other things) was taken from GUS
project.

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

This should be ok with only some small modifications in snd_dma_malloc/free
routines to allocate continuous pages without GFP_DMA flag. Fragment
should be aligned by value specified by lowlevel code... I'll try change
code of these functions to be more universal.

My questions is, if we can assume, that most of hardware will use
continuous memory as ISA DMA buffer or DMA buffer in kernel/device memory.
This makes three possibilities where can be buffer stored:

1) ISA DMA kernel memory space (<16MB)
2) anywhere in kernel memory space
3) on device which memory is directly mapped to kernel memory space
   (PCI memory mapping for example)

Other soundcard will probably use own code for buffer operations.

> - It has one stereo ADC and two stereo DAC's, with somewhat
>   hackish 4 channel mode.

No problem. You can make 1 PCM device with playback & record ability and
second PCM device with playback only (if DAC's can be programmed
separately). This doesn't assume use of 4 channel mode for playback, but
it can be used from user space. Note: What about synchro ioctl's for PCM
to allow start/stop record/playback with two or more devices at one time
to make this thing more precise? Anyone from application programmers have
some idea?

						Jaroslav

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


