From alsa-devel-owner@alsa.jcu.cz  Wed Mar 25 21:25:18 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 VAA08103
	for <alsa-devel@jcu.cz>; Wed, 25 Mar 1998 21:25:10 +0100
Received: (qmail 15904 invoked from network); 25 Mar 1998 20:25:08 -0000
Received: from dialppp-1-111.rz.ruhr-uni-bochum.de (HELO localhost) (root@134.147.1.111)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 25 Mar 1998 20:25:08 -0000
Received: by ruhr-uni-bochum.de
	via sendmail with stdio
	id <m0yHwk4-000NM1C@localhost> (Debian Smail3.2.0.101)
	for alsa-devel@jcu.cz; Wed, 25 Mar 1998 21:25:44 +0100 (CET) 
Message-ID: <19980325212544.36238@flora>
Date: Wed, 25 Mar 1998 21:25:44 +0100
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Jaroslav Kysela <perex@jcu.cz>
Cc: alsa-devel@jcu.cz
Subject: Re: C++ API premises...
References: <19980324012717.02641@flora> <Pine.LNX.3.96.980325194707.866A-100000@entry.jcu.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.LNX.3.96.980325194707.866A-100000@entry.jcu.cz>; from Jaroslav Kysela on Wed, Mar 25, 1998 at 08:43:38PM +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Wed, Mar 25, 1998 at 08:43:38PM +0100, Jaroslav Kysela wrote:
> 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...

This would be great, thank you!
 
> > ... 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).

Sure, I think this is partly why I was not satisfied by the current
situation.
 
> > > 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";

Looks good! I like the device names (not containing the name of the
soundcard).

[snip for brevity]
> 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 );
> }

I would use an array here (as for snd_error):

char* SND_MIXER_NAMES[] = { "Master", "PCM", ... }

but still you would have to change at least two places to implement more
devices...

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

? You probably mean "no 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.

Well, the strings would reside in driver space, so I can't see where the
implementations differ in user space. But you are right that the information
would be spreaded using int's. 
 
> 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..

Yes.

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

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

I think you are doing great work here. I don't doubt your decision in any
way, I just want to understand...

Well, am I correct that the bothimplementations (int & char*) don't differ
from the user (library and application) point of view? I mean, they use the
macros and that's it. Any further information has to be added by the kernel
driver anyhow. (?)

I really should read the driver code instead bothering you. But I
concentrate on the library code by now, so I don't get tempted to circumvent
the library when implementing C++ interface ;)

Thank you for the explanation,
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

