From alsa-devel-owner@alsa.jcu.cz  Sun Mar 22 11:24:30 1998
Received: from entry.jcu.cz (perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id LAA07693;
	Sun, 22 Mar 1998 11:24:27 +0100
Date: Sun, 22 Mar 1998 11:24:27 +0100 (MET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
cc: alsa-devel@jcu.cz
Subject: Re: C++ API premises...
In-Reply-To: <19980322022441.64619@flora>
Message-ID: <Pine.LNX.3.96.980322110125.14568C-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, 22 Mar 1998, Marcus Brinkmann wrote:

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

Information can't be changed for soundcard while you have valid handle
for control interface. Every open call to kernel locks the last soundcard
module (module is in use).

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

At this time if you pass valid structure to info function, an error can't
occur in normal case. If some error occurs at this point, you can abort
program and say to user that fatal error was occured.

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

Note that PCM device is exclusively locked when you use PCM interface
(not control interface)!!! Same situation maybe for future devices, too...
Classes for all interfaces should be separated. You can assume that
static info structures can't be changed while appropriate interface is
opened. This affects all info structures:

snd_ctl_hw_info
snd_mixer_info_t, snd_mixer_channel_info_t
snd_pcm_info_t, snd_pcm_playback_info_t, snd_pcm_record_info_t

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

I think that this isn't really needed. Library should do some form of
info caching, but it must open always one interface to make sure, that
driver is locked and can't be unloaded from system at this time. Control
interface should be good for this...

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

No comments...

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

				Jaroslav

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



