From alsa-devel-owner@alsa.jcu.cz  Thu Mar  4 22:02:33 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 WAA28042;
	Thu, 4 Mar 1999 22:02:09 +0100
Date: Thu, 4 Mar 1999 22:02:09 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Paco Andres Verdu <f.andres@usa.net>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Another mixer change proposal
In-Reply-To: <Pine.LNX.3.96.990303220557.334A-100000@Trantor.Trnet.org>
Message-ID: <Pine.LNX.3.96.990304215101.21599D-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, 4 Mar 1999, Paco Andres Verdu wrote:

> Hi,
> 
> On Sun, 28 Feb 1999, Jaroslav Kysela wrote:
> 
> > On Mon, 1 Mar 1999, Paco Andres Verdu wrote:
> > 
> > >   To summarize it : A mixer is composed of switches (routing and nonrouting
> > > ones) and channels (devices), which in turn are composed of switches and
> > > sliders. The number of of channels, switches and sliders should be
> > > dynamically variable after having registered the device,  maybe an
> > > 'update_mixer' function ?.
> > 
> > The dynamic mixer change is very hard nightmare for me and the application
> > programmers, but the idea is nice.
> 
>   I agree with you, it could be very difficult to implement true dynamic
> channel/switches/sliders, but maybe we can obtain almost the  same
> functionality with an "active" flag in sliders/switches (if this flag is
> false that means that changing the value of the slider/switch wouldn't
> affect the output), and a "changed" flag in the mixer and channels that
> would indicate that the "active" status of one (or more) of it's
> switches/sliders has changed.
> 
>   That way, if an application choose to ignore these flags there wouldn't be
> any adverse effect (aside from the app wasting some resources setting
> switches/sliders that don't affect the soundcard's output), and if an
> application checks these flags it can get (and present to the user) a more
> accurate view of the device.
> 
>   These flags should be a lot easier to implement than the dynamic
> registering/unregistering of sliders.

Yes, I had exactly same idea. 

> > >   I think that the volume settings of each device should be done on the
> > > mixer (as they are done in real world) rather than in the device itself, buy
> > > maybe a pointer on each device, whose volume could be set, to it's
> > > associated mixer channel would be helpful.
> > 
> > I don't think so. The balance of voice among speakers (or subvolumes for 
> > each speaker) and the final volume for speakers are different things. 
> 
>   Yes, they are different things, but that doesn't mean that they should be
> done in different places. I see the point that putting the direction
> operations in PCM the use of this operations would be easier for application
> programmers using them, but IMHO it would add unnecessary complexity to of an
> ALSA driver, because:
> 
>    - Almost any device which has a volume (wavetable syntetizers, CD Audio,
> static (mod) voices, FM syntetizers, etc) can have a direction, at least in
> Dream's DSP's many of these devices have a direction (in fact one of them
> has two pan sliders one for the left line and one for the right one).
> 
>      If we add direction operations to the PCM channels, why not add these
> operations to the rest of devices?. The only thing that all these devices
> have in common is that all of them have an associated mixer channel to set
> volumes, in fact the way of adding direction to these sounds is by modifying
> the relative (to the main volume output) volumes of the four speakers for
> this channel. 
> 
>    - The task of making applications easier to program is work for the ALSA
> library, not for the device drivers. If the soundcard driver provides a pointer
> in the device structures to they associated mixer channel ( something like
> pcm->mixer_chn = SND_MIXER_PRI_PCM ) the library could easily provide
> direction operations for the pcm devices, or any other device, hiding the
> mapping between the device and the mixer channel inside the library. That
> way (imho) we will retain the benefits of applications easier to program
> and simpler and easier to debug drivers.
> 
>  Please, don't misunderstand this note, I'm only expressing some ideas and
> caveats about this issue, not talking as 'the one with the truth' nor
> telling anyone how things should be done.

Don't worry. I and Abramo are opened for these things. We'll probably
implement them in 0.3.0pre6 (0.3.0pre5 will come out with some unstable
mixer interface).

Things to implement (0.3.0pre6):

	- better description which mixer channel is used for other devices
		- PCM,SYNTH etc..
	- better description of signal routes between mixer channels
	- better description of signal routes between voices
	- add more voices than two
	- add a position to voices (front-left, front-right, rear-left etc..)
	- add hardware effect(s) to signal routes
	- two different voice types (speaker,balance)
	- maybe add ACTIVE/CHANGED flags to controls
	- maybe more..

							Jaroslav

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


