From alsa-devel-owner@alsa.jcu.cz  Thu Mar  4 21:29:16 1999
Received: from mascarat.dragonet.es (dragonet.es [194.179.92.6])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id VAA25197
	for <alsa-devel@alsa.jcu.cz>; Thu, 4 Mar 1999 21:28:38 +0100
Received: from Trantor.usr.dragonet.es (root@dinamic1-107.drago.net [195.76.196.107]) by mascarat.dragonet.es (8.8.7/8.7.3) with ESMTP id VAA03061 for <alsa-devel@alsa.jcu.cz>; Thu, 4 Mar 1999 21:27:05 GMT
Received: from Trantor.dragonet.es (4748 bytes) by Trantor.usr.dragonet.es
	via smail with P:bsmtp/R:smart_host/T:smtp
	(sender: <f.andres@usa.net>) 
	id <m10IejO-000Y2YC@Trantor.usr.dragonet.es>
	for <alsa-devel@alsa.jcu.cz>; Thu, 4 Mar 1999 21:28:30 +0100 (CET)
	(Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jul-16)
Received: from localhost (really [127.0.0.1]) by Trantor.Trnet.org
	via in.smtpd with esmtp
	id <m10Icfj-0008YVC@Trantor.Trnet.org> (Debian Smail3.2.0.101)
	for <alsa-devel@alsa.jcu.cz>; Thu, 4 Mar 1999 19:16:35 +0100 (CET) 
Date: Thu, 4 Mar 1999 18:16:35 +0000 (GMT)
From: Paco Andres Verdu <f.andres@usa.net>
To: alsa-devel@alsa.jcu.cz
cc: Paco Andres Verdu <f.andres@usa.net>
Subject: Re: Another mixer change proposal
In-Reply-To: <Pine.LNX.3.96.990228215258.11253J-100000@entry.jcu.cz>
Message-ID: <Pine.LNX.3.96.990303220557.334A-100000@Trantor.Trnet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

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.


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


Paco
 

                              Saludos

-----------------------------------------------------------------------------
Paco Andrs Verd                                           f.andres@usa.net
Alicante (Spain)                                              



