From alsa-devel-owner@alsa.jcu.cz  Mon Nov  9 21:32:27 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 VAA22289
	for <alsa-devel@jcu.cz>; Mon, 9 Nov 1998 21:30:33 +0100
Received: (qmail 29578 invoked from network); 9 Nov 1998 20:30:31 -0000
Received: from dialppp-1-156.rz.ruhr-uni-bochum.de (HELO localhost) (mail@134.147.1.156)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 9 Nov 1998 20:30:31 -0000
Received: from brinkmds by localhost with local (Exim 2.02 #1 (Debian))
	id 0zcxz4-0006fO-00; Mon, 9 Nov 1998 21:32:22 +0100
Message-ID: <19981109213222.A23887@ruhr-uni-bochum.de>
Date: Mon, 9 Nov 1998 21:32:22 +0100
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Jaroslav Kysela <perex@jcu.cz>
Cc: alsa-devel@jcu.cz
Subject: Re: About Mixer callback
References: <19981108010810.C25996@ruhr-uni-bochum.de> <Pine.LNX.3.96.981108210641.9030E-100000@entry.jcu.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.LNX.3.96.981108210641.9030E-100000@entry.jcu.cz>; from Jaroslav Kysela on Sun, Nov 08, 1998 at 09:15:27PM +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Sun, Nov 08, 1998 at 09:15:27PM +0100, Jaroslav Kysela wrote:
> On Sun, 8 Nov 1998, Marcus Brinkmann wrote:
> > 
> > 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
> 
> Yes, change status is relative from last call...
> 
> > have to update the information of _all_ channels with each request. This is
>                                     ^^^^^
> Why? Callback says exactly (with channel number) which channel was
> modified. Why update all channels?

Ups, I certainly meant, all channels _which have changed_ since the last
call for an update.

_If_ the Channel buffers the data, it has to know when to update it. This is
done by callback. However, as you say above, if I use callback, I have to
update all changed channels, if only one device handle is used (as you explain
further below, I could use one handle for each channel...). This is outside
of the scope and possibility of one channel instance (well, there _are_ ways
to go around this limitation, but I wouldn't call them nice).

Going through a loop to check all channels if only the status of one channel
is needed seems to be wasted time for me. OTOH, updating channels
unnecessary is wasted, too. There is only one way: I will implement both and
see what is faster. I will report my results back to this list, just FYI.

> > 1) expensive (if a lot of channels have changed)
> > 2) makes it rather impossible to seperate the channel structure from the
>                      ^^^^^^^^^^^^^^^^^^^^^^
> It isn't true. You can simply open next connection (snd_mixer_open) to
> mixer with new file descriptor and ignore all callbacks except callbacks
> for selected channel. I'm only not sure if there will be open 500 mixers
> if updating willn't be very slow, but I hope that not...

Ah, I see. However, I don't like to open more handles then are needed.
Currently, one application that uses alsa-lib++ uses at most one handle per
device. I don't want to change that.
 
> > > 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
> 
> No, there is nothing needed on application (library) side (only accepting
> change callbacks)...

Well, I thought this is an error condition, and certainly I want to report
this using C++ exception handling. However, I don't know what I am talking
here about (as I know nothing of this feature yet). Callbacks will be
possible using class derivation, however.
 
> > 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 :)
> 
> I'm sorry, documentation is for me always last thing for non-pre version
> of driver (I'm always busy with other things) :-(((

Sure, I understand that. I will have to read the sources anyway. I certainly
didn't want to complain (you are doing a great job Jaroslav!).

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

