From alsa-devel-owner@alsa.jcu.cz  Tue Mar 10 18:15:29 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 SAA10105;
	Tue, 10 Mar 1998 18:15:21 +0100
Date: Tue, 10 Mar 1998 18:15:21 +0100 (MET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Thomas Sailer <sailer@ife.ee.ethz.ch>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Mixer
In-Reply-To: <35056799.4057@ife.ee.ethz.ch>
Message-ID: <Pine.LNX.3.96.980310180108.5232H-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 Tue, 10 Mar 1998, Thomas Sailer wrote:

> Jaroslav Kysela wrote:

> Yes, this is the netlist approach, you essentially "draw"
> a schematic of the mixer, quite like an electrical
> engineering schematics program. This is certainly the most flexible
> and the only way to represent every feature of the mixer,
> but makes it somewhat difficult for the application.
> But if the library provides enough functions to manipulate
> that it's certainly doable...

Yep, but I think that we can implement in most cases this feature to
library and make driver doing only low-level job. Library should 
have some kind of language which will describe mixer scheme.
Library should detect which mixer is present in the system from
info structure which gives to application chip name.

> > At this point can be a little bit difficult to detect Master (output)
> > channel, but this should be done by testing of channel name. Master should
> > be first channel, too.
> 
> If we use a netlist approach, we would have the following elements
> (possibly more)
> 
> Ports
> Volume elements (with boundary/step size)
> Switches
> Summing elements
> Special functions like low/high pass filters
> (Wires implicitly)
> 
> Ports would then have attributes, such as
> input/output, what kind of input/output (such as
> Mic, Line, ADC, DAC, headphone out, line out etc.)

I agree... Now we can make some discussion which elements/parts should go
to driver and which to library... Probably only volume elements + other
mixer things which must be setup in kernel space should be in the driver
and other (such as summing elements) should be in library. These elements
doesn't give to driver more functionality.

> > There should be done some changes in API for multitrack PCM (Gravis
> > UltraSound), too.
> 
> What do you mean by multitrack? Cards with more than 2 channels?

Yes... There is needed to setup volume for each channel indenpendently if
you are using more than two voices.

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


