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. 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. Response: This depends on the function used to do the conversion. uint32_t type = SND_MISC_DB_SCALE; uint32_t length = length of following data; /* In this example it will be 20 */ uint8_t data[] /* data returned from sound card driver info2() */ Note: the info2(kctl, 1, &info2). The "1" tells the driver to return info2 info about the db_gain function. For example, if it was "2", we could(not implemented yet) get the driver to return all the info returned in the current info() function, but in TLV form. In a simple example the data[] contains: uint32_t type = 1 /* For simple dB = (X * db_per_devision) - db_offset */ uint32_t length = 12 /* 3 following uint32_t */ int32_t db_per_devision; /* Use db per devision * 100 */ int32_t db_offset; /* Use dB offset * 100. This identifies the 0dB point */ int32_t db_mute; /* The value, before conversion, that is equivalent to MUTE */ There is the potential to request multiple parameters by encapsulating more different TLVs in the same request, but this example only used one for simplicity. If the conversion, % to dB, function is more complex, on would add a new type, e.g. 2, and then as much data as needed to describe the function. One would then implement the type 2 processing in alsa-lib. If there is a mismatch, and the user lib is of a different version from the kernel, and the required type is not implemented, the GUI mixer app would simply not display dB gain levels, as is the case with the current alsamixer. James _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
