From alsa-devel-owner@alsa.jcu.cz  Fri Mar 12 21:04:39 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 VAA07273;
	Fri, 12 Mar 1999 21:04:21 +0100
Date: Fri, 12 Mar 1999 21:04:21 +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: <36E92285.6E12A627@racine.ra.it>
Message-ID: <Pine.LNX.3.96.990312205102.1901F-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 Fri, 12 Mar 1999, Abramo Bagnara wrote:

> Jaroslav Kysela wrote:
> > 
> > On Thu, 11 Mar 1999, Abramo Bagnara wrote:
> > 
> > > 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.
> > > 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.
> 
> 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 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.
> 
> I think that an excessive fragmentation of controls (i.e. the volume/mute
> splitting) doesn't help and it will bring needlessly far from OSS.
> 
> >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.

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

> > - dynamic adding/removing of elements
> >   - maybe this could be done with some ACTIVE flag for each element
> 
> This is not sufficiently flexible.
> I think we would have to leave the possibility to loaded module to add element
> when loaded and remove when unloaded.
> Think about a software 3d effector loaded in kernel space (this has been an idea
> that I've seen in alsa-devel).
> Also if we don't like kernel space effector I feel that this possibility will
> show useful.

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.

> BTW: A chain of PCM data processing function to call after the receiving of data
> from user space would help too ;-)

It isn't problem.

							Jaroslav

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


