From alsa-devel-owner@alsa.jcu.cz  Sun Mar 22 02:54:00 1998
Received: from sunu450.rz.ruhr-uni-bochum.de (sunu450.rz.ruhr-uni-bochum.de [134.147.222.33])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id CAA14882
	for <alsa-devel@jcu.cz>; Sun, 22 Mar 1998 02:53:37 +0100
Received: (qmail 23376 invoked from network); 22 Mar 1998 01:53:31 -0000
Received: from dialppp-1-113.rz.ruhr-uni-bochum.de (HELO localhost) (root@134.147.1.113)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 22 Mar 1998 01:53:31 -0000
Received: by ruhr-uni-bochum.de
	via sendmail with stdio
	id <m0yGZVB-000NLqC@localhost> (Debian Smail3.2.0.101)
	for alsa-devel@jcu.cz; Sun, 22 Mar 1998 02:24:41 +0100 (CET) 
Message-ID: <19980322022441.64619@flora>
Date: Sun, 22 Mar 1998 02:24:41 +0100
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: alsa-devel@jcu.cz
Subject: C++ API premises...
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


Jaroslav and all,

thank you for the new version of alsa.

I have some ideas for the design of the C++ API, but am a bit unsure about
the premises I can make. 

The question is how much info about the sound driver I can collect without
making wrong assumptions. I know I'm very paranoid here, but it is a
fundamental question to the design of the internals of the API (but it does
also effect the interface).

The info structures (namely snd_ctl_hw_info, snd_pcm_info, snd_mixer_info,
snd_mixer_channel_info and possibly other now and later), are they subject
to changes over time? Is there any valid possibility that I get two
different structures given the same soundcard/device/channel, without
releasing the handle? I think "no", because the information looks very
static, and the driver can't be replaced as long as I occupy a handle, but
please correct me if I'm wrong here.

The second question is about the error code of the info request function of
the C API. If I give valid input, in what cases may an error occur (as long
as I have the handle and a valid channel number for example, how can the
channel_info request function ever return an error code)? Do temporary
errors occur when requesting such infos (e.g. would there be a reasonable
chance that a later try would succed instead)?

The background (sorry for the length):

I can either collect the information right at the beginning of the API code.
Then I could provide crosslinked container classes (vectors) to store the
various devices. This would give easy access to them, as all info is
directly available. One could, for example, easily iterate through all
mixers and channels. Or one could easily iterate through all devices of a
sound card. However, to do this, I would have to collect *all* info at once,
and *one* error would leave the interface in a doubtful state.

The other possibility would be to "remember" as little info as possible, and
requesting all info dynamically whenever requested. This would involve more
run time, but would be less critical when errors occure. Drawback: Hardly a
useful list of devices (for example) could be created, the application would
"only" see a part of the whole thing at the same time, whereas the above
solution would give overview about the possible sound devices right at the
start.

Note that this all is only about information gathering, not about actions.
For example, reading the actual volume settings of a mixer device is done
when requested, and never else.

From a design point of view, I would favor the first solution (it is easier
for applications, as they only need one class that provides all
informations, pointer to devices etc.) I wouldn't care about errors that
only occur when something is really wrong, but I do care about errors that
can be fixed at run time (for example, wrong permissions on the device
file).

A third possible solution (technically the most difficult one) would be to
provide a interface that looks like a static overview, but is calculated at
run time. I'm not at all sure if an d how this can be implemented, but time
will probably reveal something...

Any ideas are welcome.

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

