From alsa-devel-owner@alsa.jcu.cz  Fri Mar 12 12:14:14 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 MAA30887;
	Fri, 12 Mar 1999 12:13:05 +0100
Date: Fri, 12 Mar 1999 12:13:05 +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: <36E77ECE.F939D084@racine.ra.it>
Message-ID: <Pine.LNX.3.96.990312110154.1133G-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 Thu, 11 Mar 1999, Abramo Bagnara wrote:

> 1ST PROPOSAL:
> Taken for granted that esound (or something equivalent) will provide to the
> applications the multiple PCM mixing, we can provide to esound the possibility
> to ask to hardware to do the mixing.
> Imagine that esound is playing 5 different stream on an hardware capable of 4
> independant PCM. Esound will distribute the first 3 to an hardware channel and
> the last 2 will be software mixed to the last channel.
> My proposal is that one card has only one pcm device /dev/snd/pcmC0, this device
> can be opened multiple time (as many as hardware permits), can be queried for
> the number of hardware pcm supported, can be ioctl'ed to select one of hardware
> pcm, can be ioctl'ed to set volume, etc.
> This give also the possibility to OSS application to use all the hardware PCM
> available.
> Of course there is no reason to drop the PCM volume settings from mixer, we can
> leave to applications two way to reach the same goal.
> This can be accomplished changing the gold mixer structure from:
> mixer channel direction voice
> to
> mixer channel direction subchannel voice

I must say that I don't see any benefit from this solution (the multiple
open). ALSA can handle ALSA handle up to 16 PCM devices per soundcard at
the current time. This number is only limited by minor numbers and it will
be removed in the future when we will use devfs.

The problem is not that ALSA doesn't allow the multiple open, but the
problem is that we don't have drivers which supports multiple PCM devices
(for example for the synthesizer on the GUS cards) yet.

I'm not also sure if EsounD doesn't preffer open only one PCM device with
more than two PCM voices. This feature is already supported by the GUS
driver.

The volume change can be implemented to the PCM interface.

> 2ND PROPOSAL:
> I propose to add to persist module a proc interface for saving and restoring the
> settings between reboot.

This is nice idea (I had some thoughts about it before you), but this
feature have got low priority for me, thus I have not been implemented it
yet. The persist module is mainly designed for the kerneld/kmod support.

> This make alsactl (and its complexities) obsolete and yeld the persist module
> more more interesting also for other modules.

No, I don't think that the persist module can replace the alsactl program.

1) the contents of the alsactl configuration is readable/writeable
   by a human
2) the alsactl configuration file can be used eventually without
   information lost with the new versions of the ALSA driver

> 3RD PROPOSAL:
> Mixers has two faces:
> The first is that of the unordered collection of volume control and switches
> that we have implemented in alsa-driver.
> The second is the user interface needed to show to users current settings, to
> permit them to change this settings and to get a visual feeling of what happen
> when this control are changed.

I agree.

> We have taken for granted that this user interface is identical for all mixers
> and we have got all the possible efforts to accomplish this.
> I think that this is a mistake.
> A better way may be this:
> - alsa mixer interface gives to applications the possibility to read and write
> all controls (as currently does)
> - alsa mixer interface gives to modules the possibility to add and remove
> controls and to change suggested user interface
> - alsa mixer interface give to applications the possibility to read the
> suggested user interface (perhaps using /proc)
> - mixer application display user interface (according to its graphics
> capabilities)
> 
> The mixer user interface can be described using an opportune grammar.

I had a lot of thoughs about the new mixer structure. We probably must
describe some block diagram, how is the signal routed inside the
soundcard. I think that Thomas Sailer had some similar thought.

- to separate all mixer controls to single elements
- to make routes between elements

For example very simple soundcard:

LINE-IN ---- <volume1> --+-- <mute1> --- <output analog mixer1> ---- LINE-OUT
                         |
                         |
                         +-- <mute2> --- <input analog mixer1> ---- <ADC>

1. element - LINE-IN (signal source) - external analog input -> 2. element
2. element - <volume1> -> 2.element, 3.element
3. element - <mute1> -> 5.element
4. element - <mute2> -> 6.element
5. element - <output analog mixer1> -> 7.element
6. element - <input analog mixer1> -> 8.element
7. element - LINE-OUT (termination)
8. element - ADC (termination)

-> means pointer to next element(s)

What will do the driver? The driver will show to an application whole list
of all elements and allow to control (read/write) each elements. The
application could determine the mixer block diagram from this list and can
visualize the mixer to an user.

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.)
- dynamic adding/removing of elements
  - maybe this could be done with some ACTIVE flag for each element

							Jaroslav

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




