From alsa-devel-owner@alsa.jcu.cz  Sat Mar 13 00:49:24 1999
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id AAA23525
	for <alsa-devel@alsa.jcu.cz>; Sat, 13 Mar 1999 00:48:28 +0100
Received: from igor.opun.it (ppp11-nas0.faenza.nettuno.it [193.207.49.140])
	by bologna.nettuno.it (8.8.6/8.8.6/NETTuno 3.1) with ESMTP id AAA14960;
	Sat, 13 Mar 1999 00:48:25 +0100 (MET)
Received: from racine.ra.it (localhost [127.0.0.1])
	by igor.opun.it (8.8.8/8.8.8) with ESMTP id AAA10375;
	Sat, 13 Mar 1999 00:45:54 +0100
Message-ID: <36E9A732.8CA36DA9@racine.ra.it>
Date: Sat, 13 Mar 1999 00:45:54 +0100
From: Abramo Bagnara <abbagnara@racine.ra.it>
MIME-Version: 1.0
To: Jaroslav Kysela <perex@jcu.cz>
CC: alsa-devel@alsa.jcu.cz
Subject: Re: Some proposals
References: <Pine.LNX.3.96.990312205102.1901F-100000@entry.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Jaroslav Kysela wrote:
> 
> On Fri, 12 Mar 1999, Abramo Bagnara wrote:
> 
> >
> > If all cards that support hardware mixing of many DAC sources work in the GUS
> > way (i.e. receive the data interleaved), this proposal is to forget.
> > I believed that this was not the only way...
> 
> > If I understand well, to receive the data not interleaved we would need a DMA
> > channel for every source... Am I right?
> 
> Yes, but this is another problem. The problem, which you are describing,
> is only how to deal with the hardware which allows more simulteneous PCM
> devices. The question if the devices will be allocated dynamically or if
> user will specify the number of devices at the driver load time and how
> will be these devices addressed.

I think that it's not a good idea to add 32 or 64 static device with different
names.
Also I think that fixed rate interleaved multiple PCM (like GUS) is better
handled with current interface (I suppose it's near impossible to handle with
independant device in a neat way).
If the card support many independent channel (different data format and rate) I
think that the multiple open way is a superior solution.
We can expect that this cards will become more diffuse in near future.
Take in account that using multiple open we do not need to change any existant
application (especially the OSS ones).


> > >From your outline is missing the element constraints (by example exclusive
> > record source).
> 
> :-)) Please, try to think about my idea. The "exclusive record source"
> will be next element (the element which will select output from exactly
> one input). The power in this design is in the routes. These routes will
> describe things which we must destribe by some flags, constraints etc in
> the current design.
> 
> Next power is in the flexibility. We could add more elements (if necessary)
> in the future.

I don't think that routes are so important.
Please follow my view:

a) mixer lowlevel add and remove this kind of controls:
- channel control (for each voice (left, right, ecc.) volume level, mute, route
path and optionally a standard volume setting (min, max, default))
- switches
(channel control is really only a complex group of switches grouped for
convenience)

b) mixer lowlevel inform midlevel about all mixer constraints to deny to
application invalid use of controls.

c) mixer lowlevel give to midlevel the description of a suggested user interface
to pass to applications. This will comprise not only route between elements but
also all info needed to build a descriptive user interface.

d) all modules loaded can add (and remove) other controls and add/remove element
to suggested user interface.

e) mixer midlevel give application the possibility to change controls setting
and to know the suggested user interface. It will inform application for any
add/remove of controls or changes in the user interface.

f) simple mixer application (and also existing OSS one) will access only the
controls ignoring the suggested user interface

g) complex mixer application will implement the suggested user interface
according to their graphic capabilities.

We can also decide to not make kernel space heavy and to not inform ALSA about
user interfaces.
This can be accomplished simply by giving an user interface definition file as
argument to mixer application. It would not be dynamic and fool proof but
perhaps it's a possibility to take in account.

Following these guidelines we need to define:
- a mixer constraint grammar
- an user interface grammar

But before all: this design will comprise *all* mixer requirement from now to
eternity? ;-)

We need to ponder over, please contribute. 

> > > The problems:
> > >
> > > - OSS mixer API emulation
> > >   - ??? I haven't other idea than we could write the next interface for
> > >     the OSS API to each lowlevel driver. (I don't like this idea.)
> >
> > If we leave volume and mute control (record source) together we don't need to
> > modify current implementation, I think...
> 
> It isn't possible with the block diagram description design. Otherwise we
> will same problems as in the current implementation.

I can't understand how we would compromise your design allowing both a volume
control element and a volume_and_mute control element.
Can you explain better?

> The main problem with some dynamic design is how to propose the changes to
> the applications. I think that we can do this only with some "rebuild"
> event. After receiving of this event the application may load the new
> mixer structure. It would be also fine, if the element identificators
> won't be changed.

It's perfect.

--
Abramo Bagnara                       mailto:abbagnara@racine.ra.it

Opera Unica
Via Emilia Interna, 140              Phone: +39.0546.656023
48014 Castel Bolognese (RA) - Italy  Fax:   +39.0546.656023

