From alsa-devel-owner@alsa.jcu.cz  Sun Feb 28 23:32:35 1999
Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id XAA13914
	for <alsa-devel@alsa.jcu.cz>; Sun, 28 Feb 1999 23:31:05 +0100
Received: from mediaone.net (cekim.ne.mediaone.net [24.128.198.87])
	by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id RAA25547
	for <alsa-devel@alsa.jcu.cz>; Sun, 28 Feb 1999 17:31:03 -0500 (EST)
Message-ID: <36DB167A.86B852C2@mediaone.net>
Date: Mon, 01 Mar 1999 17:36:42 -0500
From: root <cekim@mediaone.net>
MIME-Version: 1.0
To: alsa-devel@alsa.jcu.cz
Subject: Re: Another mixer change proposal
References: <Pine.LNX.3.96.990228130341.418A-100000@Trantor.Trnet.org>
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

If this has been said, just add me to the list of whiners, of not, here
goes... (not a rant about what trident has done they seem to have done
it the RIGHT way in this case)

My only comment to offer to the discussion of binary driver support is
to say that poses a serious problem to Linux's support of multiple
platforms (alpha,sparc,ppc, whatever non-intel wiz-bang MPU that comes
out next).

I use Alsa primarily to get SBAWE support (much better support than OSS
at least) on my alpha.

As such, I have really come to appreciate open source for drivers as it
has allowed to me to use drivers not yet compiled for my machine, fix
drivers compiled but not fully functional, and at least one case create
a driver where none existed.

In the case of DSP firmware for subcomponents of the card, so long as
that firmware is independent of the architecture of the host then binary
subcomponents are fine.  the less I need to know the better (so long as
I don't NEED to know it of course). 

Perhaps PCI/ISA architectures have become common ground with Sun AXi and
ALpha's using them now, but still endianness and DMA quirks leave some
hang-ups if the DSP needs to do things off the sound card.

Cross platform performance/API is one of THE things which keeps linux
ahead of MS and will continue to do so.  There is no reason we as
consumers should be stuck buying inferior hardware (at any given moment)
simply because software vendors and peripheral vendors will not provide
enough information to create or obtain driver support.  

That is why MS and Intel are where they are today (don't get me wrong, I
am an adamant money grubbing capitalist, but I don't appreciate the fact
that I have to deal with slower buggy hardware or nothing at all when
better, faster, affordable things are available

I acknowledge that things will be harder for me if I choose to use PPC,
alpha or sun for my system, but the beauty of the linux model to has
been that the headaches are confined to pointer weirdness and compile
flags (for the most part) not the fundamental operation of the code.

If this is to be a step forward(vendors providing specs/app notes for
their cards, or even drivers) it should take linux's multiplatform
support into account.  Not that they MUST provide golden source for
every platform out there, just thin information for us wierdos to
getting it working. 

If they want to use a GPL'd API/lib such as ALSA will be (eventually)
and then provide a URL to binaries with all the platforms linux
supports, that would be sufficient too.  More likely is that they will
support what the "majority" market share is and that is what I would
like to avoid.

I would like to offer my sincere thanks to Trident for offering
assistance seemingly without all of these issues to deal with in this
case.

/Mike 



Paco Andres Verdu wrote:
> 
> On Sat, 27 Feb 1999, Abramo Bagnara wrote:
> 
> > Jaroslav Kysela wrote:
> >
> > > 2) Would be also the mixer to control PCM voice volumes?
> > >    - I don't think it. The mixer would control only the output volumes.
> > >      We must probably extend PCM for balance (or better PCM voice
> > >      volume setup). This volume setup wouldn't be only left and right, but
> > >      probably more universal to satisfy all things.
> >
> > The possible manipulation of PCM output are potentially infinite:
> > - 3D
> > - Balancing
> > - Routing
> > - Bass
> > - Treble
> > - Equalizer
> > ...
> >
> > We can't choose now which we will introduce at kernel level.
> > I think that the better way is to give the possibility to loaded modules to add
> > PCM manipulation and contemporary to add mixer control or switch in a dynamic
> > way.
> 
>   For soundcards based on Dream's sam9407 dsp (Guillemot Maxisound series,
> Hoontech ST series, Terratec EWS, etc) a more universal volume setup
> would be helpful ( it has four speaker volumes), but Abramo's proposal would
> be better suited since these soundcards have the ability to dynamically
> reconfigure to add/remove devices (i.e .- none/2/3/4 bands equalizer, 2/4
> speaker output, add/remove devices (surround, reverb, echo, ...), etc), the
> possibility of adding/removing mixer controls, and PCM manipulation would
> allow to support these features on the kernel.
> 
>   Since these features can be applied to any of the soundcard's channels
> (MIDI syntetiser, static wave (voices), input from the codec and PCM
> (dynamic) wave), May be these effects could be implemented as
> dynamically loaded sound processing modules (mixer channels) whose
> input/output could be routed (with routing switches) to another channels
> (the main sound output for instance).
> 
>   That way an application should be able to say: turn on the equalizer
> switch (that would make a 2/3/4 bands switch available to the application),
> set the switch to two bands (that would make four sliders avaiable, two for
> gain and two for center freq. ), connect it's input to the codec's output
> and it's output to the main output.
> 
>   The changes needed to the actual ALSA mixer structure should be minimum,
> mainly to allow for dynamic registering/unregistering of devices (channels)
> and sliders.
> 
>   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 ?.
> 
>   That way a four speaker volume control could be represented by : a switch
> that selects between 2/4 speakers, and a set of 2/4 (depending on the switch's
> position) sliders to control the volume on each speaker.
> 
>   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.
> 
>   The idea I'm trying to model is that of an HI-FI Rack Amplifier's, with
> switches to control the routing of the inputs (enabling or disabling
> devices like the bass/treble devices) to the output, and a set of sliders to
> control the behavior of these devices (i.e. .- the bass gain slider). I
> expect not to have failed to explain this idea.
> 
> 
>                               Saludos
> 
> -----------------------------------------------------------------------------
> Paco Andrs Verd                                          f.andres@usa.net
> Alicante (Spain)
> 
> ------
> To unsubscribe from <alsa-devel@alsa.jcu.cz> mailing list send message
> 'unsubscribe' in the body of message to <alsa-devel-request@alsa.jcu.cz>.

