From ultra-devel-owner@ultra.jcu.cz  Mon Mar  2 19:40:55 1998
Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id TAA11516
	for <ultra-devel@jcu.cz>; Mon, 2 Mar 1998 19:40:34 +0100
Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30])
	by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id NAA03626
	for <ultra-devel@jcu.cz>; Mon, 2 Mar 1998 13:42:34 -0500 (EST)
Received: from cyanofarm (awood.stl.vt.edu [128.173.241.58])
	by sable.cc.vt.edu (8.8.8/8.8.8) with SMTP id NAA14540
	for <ultra-devel@jcu.cz>; Mon, 2 Mar 1998 13:39:45 -0500 (EST)
Message-Id: <3.0.5.32.19980302133847.008f5600@mail.vt.edu>
Date: Mon, 02 Mar 1998 13:38:47 -0500
To: ultra-devel@jcu.cz
From: Alan Robinson <ar@vt.edu>
Subject: Re: linux/sounddetect.h
In-Reply-To: <Pine.LNX.3.96.980302100637.21931B-100000@entry.jcu.cz>
References: <3.0.3.32.19980301171220.006bcbb8@mail.vt.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: ultra-devel@ultra.jcu.cz
Sender: ultra-devel-owner@ultra.jcu.cz
Precedence: list

>>
>> First Byte:  Type of sound card, ie, chipset.  For instance, GF1.
>> Second Byte: Specific sound card. For instance, GUS-MAX.
>> Third Byte: Revision number. For instance, 1.7.
>
>To chipset - some GUS soundcards (and probably other soundcards, too) is
>combination of chipsets, so First Byte can explain nothing or will be
>differenced - this doesn't simple test contitions very much.

Hmm, good point.  Something of that nature might stilll be useful at a
device level, (ie, one code for the GF1 device, and another code for the
ESS device on the ViperMax.)  But sound cards are becoming so multifunctin
now that just one code for the entire board would not work. 

>I assume that soundcard ID will be used mainly for program which will
>manage modules. This program must exactly know what type of soundcard is
>detected (revisions specific things will be handled in driver) and load
>appropriate modules to kernel.


>I assume that soundcard ID can be used by application at last point, only
>if really needs. I think that all other stuff must be handled by API.
>
>For example - driver will say to user space that supports ultraclick
>elimination by some info flag and program will not check soundcard ID for
>it.

This sounds good.... Maybe instead of device codes, a simple set of device
flags would be better.  Another example might be an app wants to use the
synth device on a wavetable card, but wants to know what the maximum number
of channels are mixed at the highest quality level (as in 15 for the GF1).
This could be part of some sort of "spec" structure that varys between
devices (ie, we don't need to know the same specs for a wave talbe device
as for a simple DAC).

-- Alan.





