From alsa-devel-owner@alsa.jcu.cz  Fri Apr 10 17:25:07 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 RAA30494;
	Fri, 10 Apr 1998 17:24:42 +0200
Date: Fri, 10 Apr 1998 17:24:41 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Rutger Nijlunsing <rutger@null.net>
cc: alsa-devel@jcu.cz
Subject: Re: driver 0.0.10
In-Reply-To: <199804091835.UAA00836@wingding.demon.nl>
Message-ID: <Pine.LNX.3.96.980410165506.3819B-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 Thu, 9 Apr 1998, Rutger Nijlunsing wrote:

> > 	One problem still remains: How can be restored driver settings
> > after load of modules to memory.
> [snip]
> 
> According to /usr/src/linux-2.1.93/Documentation/kmod.txt:
> 
> "Kerneld also had a mechanism for storing device driver settings.  This
> can easily be done with modprobe.  When a module is unloaded, modprobe
> could look at a per-driver-configurable location (/proc/sys/drivers/blah)
> for device driver settings and save them to a file.  When a module
> is loaded, simply cat that file back to that location in the proc
> filesystem.  Or perhaps a script could be a setting in /etc/modules.conf.
> There are many user-land methods that will work (I prefer using /proc,
> myself)."

This is good idea, but not implemented at current time in modprobe/insmod.
This can't be probably used with 2.0 kernels, too.

> Another method would be to use post-install and pre-remove methods in
> /etc/conf.modules. This saves quite some memory when sound is not
> used, so I vote in favor of this method.

Nope (piece from modprobe man page):

	      Note that the pre- and post-remove commands will
              not  be  executed  if  a module is "autocleaned" by
              kerneld!  Look for the up-coming support  for  per-
              sistent module storage instead.


> Some other subjects:
> 
> * Why does the mixer go from 0 to 100 like in OSS, even when not in
> OSS mode? Every soundcard has some number of bits assigned to a mixer
> channel, so 0 to 255 would be much more logical.

ALSA driver have two modes for mixer. Percentual (0-100) and exact. You
are probably interrested with exact mode which gives to application real
range for given mixer channel.

> * Currently I have a Turtle Beach Maui as a second sound card. This
> card contains a GF1 chip, but does all the processing with an
> on-board MC68000 [Someone cares to run Minix on a Sound Card?
> :]. The MC68000 processes MIDI commands, so MIDI has not to be
> emulated. Instrument loading however, has to be emulated. Does this
> fit in the current driver model?

Current ALSA driver doesn't know anything about MIDI and synthesizer 
interfaces. It's work for near future (after 0.1.0 version of driver will 
be out). ALSA driver is written for all soundcards and if some soundcard
is very different and doesn't fit to current middle level code, programmer
should register own code and process anything system calls with separate
(but compatible) way.

> * In the long run: to succeed in bringing this driver to attention of
> a greater audience and increase the applications for the
> driver[/library], some effort should be put into porting ALSA to AFSA,
> ANSA, AOSA and other sorts [The *BSD variants]. This could be done by
> writing a native driver, or by using the native driver available and
> only writing an interface between the ALSA library and the native
> driver. For example, the library could also be written for Solaris.

Yes, I have same idea. I must again notice, that I'm now very busy
with coding driver for Linux. I don't have time to extend library, write
some native applications nor play with other operating systems. Looks that
I'm still alone and sound things doesn't go to future in the right speed.
Looks like that most of people have interresting ideas, but nobody writes
code :-(((

There are also things like ALSA WWW pages and create some publicity for
ALSA project (I'm thinking that Linux people doesn't know about this
project). I can't maintain all :-(((

					Jaroslav

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



