From alsa-devel-owner@alsa.jcu.cz  Sat Mar 13 11:42:30 1999
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id LAA03704;
	Sat, 13 Mar 1999 11:41:56 +0100
Date: Sat, 13 Mar 1999 11:41:56 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Abramo Bagnara <abbagnara@racine.ra.it>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Some proposals
In-Reply-To: <36E9A732.8CA36DA9@racine.ra.it>
Message-ID: <Pine.LNX.3.96.990313105949.2231D-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 Sat, 13 Mar 1999, Abramo Bagnara wrote:

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

OK. We could do to try something like this. We need to design some good
mechanism to allocate hardware voices (for PCM & MIDI). It would be
probably nice, if the user can choose how many voices will be allocated
for the MIDI & for the PCM.

I haven't time for some changes in the PCM interface. I need to complete
the sequencer (the instrument interface) and the unstable mixer interface.

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

Yes, they are very very important. For example MUTE (on/off switch on the
route):

LINE-IN --> <gain> --+--> <mute> ---> <analog input mixer>
                     |
                     +--> <mute> ---> <analog output mixer>

OR

LINE-IN --> <mute> --> <gain> --+--> <mute> --> <AIM>
                                |
                                +--> <mute> --> <AOM>

OR

LINE-IN --> <gain> --> <mute> --+--> <mute> --> <AIM>
                                |
                                +--> <AOM>

etc.. As you see, this very simple examples shows the possile routes.
The third example CANNOT be described with any of your enhancements.

If you want see most complex mixer, you may look to the CS4237B datasheet
(Cirrus Logic) - it's available on the ALSA ftp site. There are THREE
mixers and most of routes aren't only input & output, there are also some
loopbacks.

> 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

No, we must separate all MUTE switches, because we need to describe if
these switches are after or before gain or attenuation (the volume
control).

> (channel control is really only a complex group of switches grouped for
> convenience)

Yes, but this solution have very strange disadvantage. We must also
describe all dependencies among them.

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

Yes, but these contrains int the current design are very very complex.
I think that describing of the mixer with some block diagram will simplify
a lot of these things.

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

I don't think so. The mixer application will need only to know the element
type (thus element handling).

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

Fine. We must only investigate the static element identifiers.

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

No comments. Except that we needn't pass some user interface when the
mixer will describe the block diagram.

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

This would not be possible with my idea. I see only one way for OSS API:
to implement this way in the separate code.

> We need to ponder over, please contribute. 

I agree. Comments?

							Jaroslav

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



