From alsa-devel-owner@alsa.jcu.cz  Sun Mar 22 18:19:23 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 SAA29364
	for <alsa-devel@jcu.cz>; Sun, 22 Mar 1998 18:19:21 +0100
Received: (qmail 13811 invoked from network); 22 Mar 1998 17:19:20 -0000
Received: from dialppp-1-234.rz.ruhr-uni-bochum.de (HELO localhost) (root@134.147.1.234)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 22 Mar 1998 17:19:20 -0000
Received: by ruhr-uni-bochum.de
	via sendmail with stdio
	id <m0yGnIk-000NLmC@localhost> (Debian Smail3.2.0.101)
	for alsa-devel@jcu.cz; Sun, 22 Mar 1998 17:08:46 +0100 (CET) 
Message-ID: <19980322170846.32730@flora>
Date: Sun, 22 Mar 1998 17:08:46 +0100
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: alsa-devel@jcu.cz
Subject: Re: C++ API premises...
References: <19980322022441.64619@flora> <Pine.LNX.3.96.980322110125.14568C-100000@entry.jcu.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.LNX.3.96.980322110125.14568C-100000@entry.jcu.cz>; from Jaroslav Kysela on Sun, Mar 22, 1998 at 11:24:27AM +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Sun, Mar 22, 1998 at 11:24:27AM +0100, Jaroslav Kysela wrote:
> On Sun, 22 Mar 1998, Marcus Brinkmann wrote:
> > 
> > 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).

This is good.

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

Okay. Maybe I find some time to check the driver sources for the sort of
errors that may occur. Maybe I can catch some of them. Note that I pass
errors through, and the application has to handle them (with aborting, for
example), but I can give the application a hint about the seriousness of the
error. I can also handle errors locally whenever apropriate.

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

Sure. I think what I wanted to say was, that I mainly meant the control
interface for this. As you say below, this is a good idea. I will have a
handle for every sound card (non-exclusive), and get the information I can
without blocking anything. Whenever a request for a device occurs, acquiring
exclusive resources will be done dynamically (and released ASAP).

> Classes for all interfaces should be separated.

An application can construct classes for special devices, but for
convenience I can provide list of classes (for example, a list of all mixer
devices for a mixer application). The solely existence of the lists does not
necessarily mean that devices are open.

> 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

This is fine.

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

Okay, this is fine. I think I can now start with the implementation of the
first couple of classes.

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

Maybe I was too paranoid here. As I get more used to the library and driver 
code, I'll be more able to adress this properly.

Thank you for your help!
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

