From alsa-devel-owner@alsa.jcu.cz  Sun Nov  8 01:06:20 1998
Received: from sunu450.rz.ruhr-uni-bochum.de (sunu450.rz.ruhr-uni-bochum.de [134.147.222.33])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id BAA24378
	for <alsa-devel@jcu.cz>; Sun, 8 Nov 1998 01:06:08 +0100
Received: (qmail 3510 invoked from network); 8 Nov 1998 00:06:05 -0000
Received: from dialppp-3-60.rz.ruhr-uni-bochum.de (HELO localhost) (mail@134.147.3.60)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 8 Nov 1998 00:06:05 -0000
Received: from brinkmds by localhost with local (Exim 2.02 #1 (Debian))
	id 0zcIOo-0006t8-00; Sun, 8 Nov 1998 01:08:10 +0100
Message-ID: <19981108010810.C25996@ruhr-uni-bochum.de>
Date: Sun, 8 Nov 1998 01:08:10 +0100
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: alsa-devel@jcu.cz
Subject: Re: About Mixer callback
References: <19981107170253.A4808@ruhr-uni-bochum.de> <Pine.LNX.3.96.981107234737.8446K-100000@entry.jcu.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.LNX.3.96.981107234737.8446K-100000@entry.jcu.cz>; from Jaroslav Kysela on Sat, Nov 07, 1998 at 11:53:16PM +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


Hello,

I realized that I was not providing enough information, so here further
information for you to consider:

On Sat, Nov 07, 1998 at 11:53:16PM +0100, Jaroslav Kysela wrote:
> On Sat, 7 Nov 1998, Marcus Brinkmann wrote:
> > 
> > For the C++ API, I have to provide mixer channel info. Either:
> > 
> > + I get the information from snd_mixer_channel_read() each time the data is
> >   requested.
> > + Or I buffer the data and update only when the channel was changed.
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This is right method. The snd_mixer_channel_read() calls callback only
> if some channel has changed....

I understand that, however I am concerned that it may be more expensive.
Even more serious, I have doubts if it works at all (this possibility I
realized just now, and I'm sorry that it didn't occured to me before).
Remember that I am talking about a single channel here, and the single
channel does not know about the other channels and has no access to
their private data.

I assume after snd_mixer_channel_read() will reset the status, so successive
calls will only report changes after the last call. But this means that I
have to update the information of _all_ channels with each request. This is
1) expensive (if a lot of channels have changed)
2) makes it rather impossible to seperate the channel structure from the
   mixer. This means, that I can't treat a channel as a single object.

Although you can argue that a mixer contains all channels, this would mean
the C++ programmer had to access the channels through the mixer class only.
This is possible, but I'm not convinced by this. This would mean that the
mixer has the channels as private data and provides members to access them.
In future extensions, it would be more difficult to connect the sound
objects to GUI objects, for example.

Once again, for clarification, a model:

Mixer class
    Callback support
    name()
    ...
    Array of Channel classes
           leftVolume()         // those seperated of each other
           rightVolume()
           ...

> Note: Driver is using these callbacks if mixer doesn't set properly record
> flags (hardware has exclusive record) and it maybe used in future for
> similar purposes...

This is interesting, and needs further investigation. Especially the impact
on the class design could be significant. Thank you for mentioning that
(btw, is this already documented? I realized that the soundapi documentation
is rather out of date. Yes, I'll go and read the sources :)

Thank you,
Marcus

-- 
"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

