From ultra-devel-owner@ultra.jcu.cz  Mon Mar  2 10:27:56 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 KAA14660;
	Mon, 2 Mar 1998 10:23:38 +0100
Date: Mon, 2 Mar 1998 10:23:38 +0100 (MET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Alan Robinson <ar@vt.edu>
cc: ultra-devel@ultra.jcu.cz
Subject: Re: linux/sounddetect.h
In-Reply-To: <3.0.3.32.19980301171220.006bcbb8@mail.vt.edu>
Message-ID: <Pine.LNX.3.96.980302100637.21931B-100000@entry.jcu.cz>
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

On Sun, 1 Mar 1998, Alan Robinson wrote:

> I don't know what the expected use of the sound card ID numbers are, but if
> the end user ever needs to get access to them, then some sort of hierarchy
> might be nice... Say the ID is a 32 bit number:
>
> 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.

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 am not sure if the revision number would really be useful, but I think
> the other two pieces of information would be useful. If application ever
> wants to know what sort of sound card it is working with (say, it wants to
> eliminate ultraclicks, if running on a GF1), then being able to check the
> chipset with a single compare would be really nice.  

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.

Any ideas?

> With the current number scheme, the program would have to check the sound
> card type, seeing if it equals SND_CARD_TYPE_GUS_ACE, SND_CARD_TYPE_ACE,
> etc. And if a new sound card came out with a GF1 chipset, then new code
> would have to be added to check for it.
> 
> Just a thought.

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


