From alsa-devel-owner@alsa.jcu.cz  Thu Apr  9 22:22:48 1998
Received: from post.demon.nl (post.mail.nl.demon.net [194.159.73.2])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id WAA02631
	for <alsa-devel@jcu.cz>; Thu, 9 Apr 1998 22:22:13 +0200
Received: from wingding.demon.nl ([195.173.249.186]) by post.demon.nl
           id aa0029555; 9 Apr 98 22:20 MET DST
Received: (from rutger@localhost)
	by wingding.demon.nl (8.8.7/8.8.7) id UAA00836
	for alsa-devel@jcu.cz; Thu, 9 Apr 1998 20:35:40 +0200
Message-Id: <199804091835.UAA00836@wingding.demon.nl>
Subject: Re: driver 0.0.10
To: alsa-devel@jcu.cz
Date: Thu, 9 Apr 1998 20:35:38 +0200 (CEST)
In-Reply-To: <Pine.LNX.3.96.980408121901.12436A-100000@entry.jcu.cz> from "Jaroslav Kysela" at Apr 8, 98 12:36:41 pm
From: Rutger Nijlunsing <rutger@null.net>
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

> 
> Hi!
> 
> 	I released new version of driver/library/utilities. Driver code
> now looks better and I added some support for PCI bus (not tested) and
> spin locking (for 2.1 SMP kernels). Some my notes about coding should be
> found in doc/coding.txt file. This document isn't complete due lack of my
> time.
> 	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)."

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.


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.

* 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?

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

Rutger.
[using ALSA for his SB16, since its the best driver currently
available for Linux]

-- 
Rutger Nijlunsing, rutger Ed null.net ---------------------------- Linux! --
Don't BiCapitalize without extremely good reason: it messes up the natural
human-eyeball search order -- Your Friendly Neighborhood Archive Maintainers
+31-40 ----------------------------------------------------------- ^X^S^X^Cs

