From alsa-devel-owner@alsa.jcu.cz  Mon Mar 23 14:20:08 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 OAA26292;
	Mon, 23 Mar 1998 14:20:00 +0100
Date: Mon, 23 Mar 1998 14:20:00 +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: <19980323040241.64574@flora>
Message-ID: <Pine.LNX.3.96.980323132536.446C-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 Mon, 23 Mar 1998, Marcus Brinkmann wrote:

> On Sun, Mar 22, 1998 at 11:24:27AM +0100, Jaroslav Kysela wrote:
> 
> > 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
> 
> I thought about this. It seems that playback & record info require a valid
> pcm handle. Jaroslav, is it possbile to move the playback & record info out
> of the pcm code and in the control code? Another possibility (probably
> easier to implement, if it is at all possible) would be a fourth open mode
> SND_PCM_OPEN_INFO, that is non-blocking and allows only snd_pcm*info to be
> called.

I think that this should be implemented to control interface rather that
special open mode for pcm interface, but I don't know if this is really
needed. Info about playback & record will application use in most cases
only if really require it. In this situation it should open pcm device for
use and thus get playback & record info.

Control interface is mainly designed for getting basic (not extended)
informations about other interfaces/devices.

> Thank you for implementing the snd_mixer_exact_mode() function. This is
> all I needed to implement all three ways to set/get volume (exact,
> percentage, decibel).

OK.. I think that mixer is now very good useable..

> 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";
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 = "SB DSP 4.16";	(device 0)
snd_pcm_info -> name = "SB ASP";	(device 1)

Application can show to user about mixer & pcm devices:

card1: Sound Blaster 16 / CTL1745

card1: Sound Blaster 16 / SB DSP 4.16
card1: Sound Blaster 16 / SB ASP

Note that pcm device 1 is only fiction at this moment ;-)

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?

snd_mixer_info -> id
snd_pcm_info -> id

It will contains id for lowlevel code. Probably not interesting for normal
application.

> A probably cleaner solution would be a char* array (similar to the error
> messages) that is referenced by the type of the card (as defined in
> sounddetect.h). the kernel driver code could reference this, too (I found 12
> literal copies of "Sound Blaster 16" spreaded over the kernel code, namely
> cards/sb16.c, detect/sb.c, lowlevel/sb/sb16.c, lowlevel/sb/sb.c, although
> some of them have been suplemented by device names ("DSP")).

I preffer rather string that some constant. Note that sounddetect.h is
mainly designed for application which will manage driver modules and not
for sound application. Type value should be used in last way...
The main reason is compatibity and functional code. Old code can pass to
application right string with soundcard name for new sound driver etc....

					Jaroslav

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


