At Mon, 29 May 2006 20:27:50 +0200 (CEST), Jaroslav Kysela wrote: > > On Mon, 29 May 2006, Takashi Iwai wrote: > > > For example, in order to get a numid, you have to extract three > > levels down. The version + length, the type + length, again type + > > length, then finally you reach to numid value. Each extraction > > requires a function call to convert from a byte-stream to an integer > > and a check of the length. I feel it's a bit too much abstraction. > > Note that such complex things reminds me - why we can't transfer all > "extra" data in one big binary array and let alsa-lib parse them? > Doing selection at the driver level seems too complex to me. TLV > structure seems good. It might also reduce the driver code, because only > a pointer to TLV data might be passed to control.c. We can create two > ioctls: > > 1) for "global" not element specific data > > u32 data_length > .... TLV data .... > u32 tlv_item_length > u32 tlv_item_type > > 2) for element specific data > > u32 data_length > u32 numid > .... TLV data .... > u32 tlv_item_length > u32 tlv_item_type > > Also, I would handle all data in the host endian type to save parsing > time. That sounds reasonable. And, yes, passing u32 array looks good to me (except for "TLV" order :) Alternatively, we can define a special numid (e.g. -1) indicating the global/unknown element. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
