From alsa-devel-owner@alsa.jcu.cz  Wed Mar 25 20:43:40 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 UAA05785;
	Wed, 25 Mar 1998 20:43:38 +0100
Date: Wed, 25 Mar 1998 20:43:38 +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: <19980324012717.02641@flora>
Message-ID: <Pine.LNX.3.96.980325194707.866A-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 Tue, 24 Mar 1998, Marcus Brinkmann wrote:

> The general pcm_info structure can give a hint about the direction the
> device supports, but for a finer graduation between the devices the playback
> and recording infos would be useful, IMO. Even when a device is busy, it
> would be nice to look at the capabilities of the device (for status reports,
> lists of all devices etc.)

I know about these things... Resume: all static information from all 
interfaces should be accessible via control interface... I make proper
changes for PCM playback/record info structures in next release...

> > > Another feature on my wishlist would be a more usable information field in
> > > the structure snd_ctl_hw_info. I get "card1" as the id and
> > > "Sound Blaster 16 at 0x220, irq 5, dma 1&5" as the name. Both are not very
> > > useful for applications to display. If it is assured that the info part of
> > > the name is always introduced by "at", this would probably be sufficient
> > > (as this can be filtered).
> > 
> > ID's & names of devices/soundcards:
> > 
> > I know that it should be implemented better. It's one from things to do.. 
> > 
> > What about (example for SB16):
> > 
> > snd_ctl_hw_info -> id = "card1";
> 
> If we have an abbreviation here...
> 
>   snd_ctl_hw_info -> abbreviation = "SB16"; /* maybe "SB 16" */

Not bad idea... Will be in next version of driver...

> 
> > snd_ctl_hw_info -> shortname = "Sound Blaster 16";
> > snd_ctl_hw_info -> longname = "Sound Blaster 16 at 0x220, irq 5, dma 1&5";
> > 
> > snd_mixer_info -> name = "CTL1745";
> 
> ... it could be used here...
>                   name = "SB16 DSP 4.16";
>                   name = "SB16 ASP";

I didn't preffer merging name strings in kernel. This should be done in
application (first part can be get from abbreviation or from shortname and
second part can be get from device name).

> > snd_pcm_info -> name = "SB DSP 4.16";	(device 0)
> > snd_pcm_info -> name = "SB ASP";	(device 1)

Next (maybe final) proposal:

snd_ctl_hw_info -> abbreviation = "SB16";
snd_ctl_hw_info -> shortname = "Sound Blaster 16";
snd_ctl_hw_info -> longname = "Sound Blaster 16 at 0x220, irq 5, dma 1&5";
snd_mixer_info -> name = "CTL1745";
snd_pcm_info -> name = "DSP 4.16";

> > About ID's:
> > 
> > snd_ctl_hw_info -> id
> > 
> > This is probably most interresant string.. This string should be modified
> > by user for module.. This string can exactly identifies soundcard rather
> > that soundcard # (for example if sound modules for more that two
> > soundcard are loaded to kernel in some cases in reverse order).. I'm
> > assuming this use if user want identify soundcard with string for
> > applications rather than with soundcard #. Any comments?
> 
> Ah. Okay, if the user can change the value of Id at insmod time, this is
> a nice thing. I find your use of strings rather than constants a bit
> unusual, but very likely I haven't realized the real benefit yet.

I'm thinking that string are in some cases more universal as types
(integers).

> Below you point out "compatibility and functional code." I'm not
> quite sure where the problems with types are (okay, the types never may
> change, but isn't the same true for strings?), but I see two problems
> with string constants as identifiers (the same applies for SND_MIXER_ID_*).
> First is run time efficiency (comparing strings is not very fast)
> and second is type checking. A miss-spelled mixer id will only be
> caught at run time, not at compile time. Well, the second point is
> well adressed by defining SND_MIXER_ID_*, so the applications
> should be urged to use them instead the real strings. The first point is
> probably not very important in the situations were the comparison is done.

OK, some comments to SND_MIXER_ID_*.

Type implementation:

#define SND_MIXER_ID_MASTER		0
#define SND_MIXER_ID_PCM		1

switch ( channel_type ) {
  case SND_MIXER_ID_MASTER: printf( "Master" ); break;
  case SND_MIXER_ID_PCM: printf( "PCM ); break;
  default:
    printf( "Uknown %i", channel_type );
}

String implementation:

#define SND_MIXER_ID_MASTER		"Master"
#define SND_MIXER_ID_PCM		"PCM"

printf( "%s", channel_type );

As you can see, string implementation is for this example more simple, but
this isn't main reason why use strings. If I want for example add
some exotic input to driver (for example phone):

Type implementation:

#define SND_MIXER_ID_PHONE		2

Printed string with above code for type implementation is "Uknown 2"...
This isn't very informative for end user...

String implementation:

#define SND_MIXER_ID_PHONE		"Phone"

Printed string with above code for string implementation is "Phone"...
This is correct result and any code in user space must be changed..
I hope that this example is a very good illustation why strings are more
universal in this case.

Searching of appropriate channel with string identificator should be more 
time consuming, but I think that this isn't in this case very important.
Soundcards have usually about 10 mixer channels..

To miss-spelled mixer id: It will be a driver bug... Driver programmer
should use SND_MIXER_ID_XXXX constants...

> Mmmh. I have the feeling that I didn't understand you at all. Sorry for
> being so dumb, but could you please explain me a bit more detailed, why
> string constants are preferable? I think I'm missing something obvious...

It's ok.. I think that we must make things clear. I'm trying in this
discussion explain my idea of the best sound interface.

						Jaroslav

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



