At Mon, 29 May 2006 15:50:01 +0100,
James Courtier-Dutton wrote:
>
> Takashi Iwai wrote:
> > At Sat, 27 May 2006 20:03:44 +0100,
> > James Courtier-Dutton wrote:
> >> Hi,
> >>
> >> I have made a new attempt at adding support for dB gain reports in
> >> alsamixer.
> >>
> >> See the attached diffs against the current alsa hg repository. 27-5-2006
> >>
> >> It shows an example of support for the snd-ca0106 driver.
> >> As one can see, this adds minimal amounts of code to each sound card
> >> driver. 22 new lines + 1 per volume control making 33 lines total.
> >>
> >> Any comments?
> >
> > Apart from some small implementation details, it looks almost fine.
> > One remaining thing is the definition of protocol. Shouldn't be numid
> > regardless of container type? Now the numid is checked inside the
> > block of db container type. I think this can be outside.
> >
> > Also, a bit more sensible names are preferred for new stuff.
> > "misc" sounds too ambiguous to me, and "info2" is...
> >
> > I'm not a native speaker, so I expect someone elese has better
> > proposal.
> >
> >
> > Takashi
>
> As for the naming, I called it misc because it can be used for anything
> we want, depending on the TLVs requested. "misc" is short for
> miscellaneous.
Yes, but it's an adjective.
So it sounds as if "snd_ctl_sexy" :)
> So I thing that "misc" is appropriate, given it's
> potential to be used for other stuff in future.
>
>
> An explanation of the protocol:
>
> The protocol is a request/response protocol
> Request:
> uint32_t version; // Protocol version
> uint32_t length; // Length of the user land data buffer. This is filled
> with the response.
> uint8_t data[]; // A block of data bytes malloc by user land,
> containing the actual "request".
>
> Inside the data one has TLVs (Type, Length, Values)
>
> For requesting db gain scales:
> Request:
> uint32_t type = SND_MISC_DB_SCALE;
> uint32_t length = 4; /* sizeof(following uint32_t)
> uint32_t value = numid; /* Used by snd_ctl_find_numid() */
>
> Note: numid is used because it is present in both userland and kernel
> land as a unique identifier of the mixer control in question.
> Of course, if we wished to get some different information, the type
> would be a different value, and the resulting value could relate to
> something else. How the value is interpreted is dependent on the type field.
I agree to use numid.
My argument is that numid can belong to the common header block.
The code you find in control.c is anyway a kind of object oriented.
It's a message to a control element.
But in this protocol, you get numid at very last, even depending on
the type. Thus the code looks like
type = get_type();
len = get_length();
switch (type) {
case DB_SCALE:
numid = get_value();
kctl = get_kcontrol(numid);
kctl->info2(kctl, ptr);
...
}
When you add more different types,
type = get_type();
len = get_length();
switch (type) {
case DB_SCALE:
numid = get_value();
kctl = get_kcontrol(numid);
kctl->info2(kctl, ptr);
...
case ANOTHER_DB_SCALE:
numid = get_value();
kctl = get_kcontrol(numid);
kctl->info2(kctl, ptr);
...
case YET_ANOTHER_DATA:
numid = get_value();
kctl = get_kcontrol(numid);
kctl->info2(kctl, ptr);
...
}
If the numid is in the common block, we can simply extract numid
first, then evaluate the type and value later, eventually call the
callback at the single place.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel
