Re: dB gain

[James Courtier-Dutton <James@superbug.co.uk>]

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