From alsa-devel-owner@alsa.jcu.cz  Fri Mar 12 15:32:58 1999
Received: from beta.queen.it (mbox.queen.it [195.223.140.121])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id PAA13954
	for <alsa-devel@alsa.jcu.cz>; Fri, 12 Mar 1999 15:31:38 +0100
Received: from igor.opun.it (isdn11-fae.e-mind.com [212.210.67.21])
	by beta.queen.it (8.9.1a/8.9.1) with ESMTP id QAA27614;
	Fri, 12 Mar 1999 16:36:29 +0100
Received: from racine.ra.it (localhost [127.0.0.1])
	by igor.opun.it (8.8.8/8.8.8) with ESMTP id PAA00615;
	Fri, 12 Mar 1999 15:19:49 +0100
Message-ID: <36E92285.6E12A627@racine.ra.it>
Date: Fri, 12 Mar 1999 15:19:49 +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.990312110154.1133G-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 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?
Please apologize my ignorance.

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

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

> - 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.
BTW: A chain of PCM data processing function to call after the receiving of data
from user space would help too ;-)

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

