From alsa-devel-owner@alsa.jcu.cz  Sun Nov  8 21:19:00 1998
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 VAA10706;
	Sun, 8 Nov 1998 21:15:27 +0100
Date: Sun, 8 Nov 1998 21:15:27 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
cc: alsa-devel@jcu.cz
Subject: Re: About Mixer callback
In-Reply-To: <19981108010810.C25996@ruhr-uni-bochum.de>
Message-ID: <Pine.LNX.3.96.981108210641.9030E-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 Sun, 8 Nov 1998, Marcus Brinkmann wrote:

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

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?

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

>    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

No, there is nothing needed on application (library) side (only accepting
change callbacks)...

> 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) :-(((

							Jaroslav

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


