Takashi Iwai wrote:
>
> 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
My point is that there will only be one DB_SCALE case in the request
handler in control.c in the kernel. It simply calls info2(). The driver
then returns a TLV. The returned TLV will have all the variations on
db_scales. control.c won't care what the actual TLV value means. It will
simply return it to user space, and let alsa-lib work out what it is.
Another call the snd_ctl_misc might not even need a numid. It might
instead be requesting some other information, like card name or some
other future bit of info needed. My point is this is extensible, without
breaking kernel/alsa-lib binary compatibility.
James
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel
