At Mon, 22 Jul 2002 21:21:47 +0200 (CEST), Jaroslav wrote: > > On Mon, 22 Jul 2002, Takashi Iwai wrote: > > > At Sat, 20 Jul 2002 09:08:29 +0200 (CEST), > > Jaroslav wrote: > > > > > > On Fri, 19 Jul 2002, Takashi Iwai wrote: > > > > > > > At Thu, 18 Jul 2002 09:03:26 -0400, > > > > Paul Davis wrote: > > > > > > > > > > why doesn't this work: > > > > > > > > > > snd_ctl_open (&handle, "hw:0,0", ...) > > > > > > > > > > it means that you can't use the same standard name format for control > > > > > devices as PCM devices, which is a bit of problem for programs that > > > > > need to open both but only want to require the user to specify a > > > > > single name ... > > > > > > > > do you suppose that the second argument of ctl name is always ignored? > > > > the control interface has no device like pcm. > > > > > > > > but it's true that having a same naming rule makes the life easier... > > > > > > The 'default' is there for this purpose. Otherwise, application / user > > > must know the right device name. > > > > iirc, it's not easy to pass the card/device number to "default" pcm. > > at least, "default:CARD=1" doesn't work. the easiest way to access a > > certain card is, so far, only to use "hw:x". > > this must be fixed. > > I don't agree here. The default is very simple case when the application > programmer doesn't want to take care about the right syntax of the device > specification. ok. so, you think that the default device is anyway exclusive, which is not used for general type to multiple devices.
> Anyway, programmers should know that CTL devices are one per card. If > there is some real need to correlate PCM handle with CTL handle, then we > might create a special function like: > > int snd_pcm_get_ctl_name(snd_pcm_t *handle, char **ctl_name); it sounds not bad. in the case of a multi pcm, it's not undetermined, though :) btw, this reminds me another thing. we have some controls which related with a certain pcm substream. and so far we have no api to pass this relationship. well, they are correlated via an index value. yes, but confusingly, a similar control can play a different role on the other driver. perhaps by similar strategy, we may implement an api function for that. > > > also, i thought that ctl.hw is defined purely in > > /usr/share/alsa/alsa.conf, and tried to redefine this to accept more > > arguments. but it doesn't change anything. is ctl.hw hardcoded? > > Extra things in configuration file are usually parsed as errors. err, no, i meant that ctl.hw seems not to be read from the configuration file... most likely i made a stupid mistake. don't take this serious yet. ciao, Takashi ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
