[alsa-devel] TLV question - ranges not in volume order
Hi,
I recently came across a strange ASoC volume control. In this case, the values are not in volume order, i e, the control is declared something like below. I believe the numbers correctly match the hardware.
However alsamixer seems not to handle this "reordering" correctly. My question is if this is something that should be fixed in alsamixer (or possibly alsa-lib?), or does one need to write some kind of mapping table in the kernel, just to make something come in volume order to userspace?
Any TLV documentation on what TLVs are valid and invalid is also welcome :-)
static const unsigned int tlv[] = { TLV_DB_RANGE_HEAD(8), 0, 0, TLV_DB_SCALE_ITEM(-100, 0, 1), 1, 1, TLV_DB_SCALE_ITEM(400, 0, 0), 2, 2, TLV_DB_SCALE_ITEM(200, 0, 0), 3, 3, TLV_DB_SCALE_ITEM(1000, 0, 0), 4, 4, TLV_DB_SCALE_ITEM(0, 0, 0), 5, 5, TLV_DB_SCALE_ITEM(800, 0, 0), 6, 6, TLV_DB_SCALE_ITEM(600, 0, 0), 7, 7, TLV_DB_SCALE_ITEM(1200, 0, 0), };
David Henningsson wrote:
I recently came across a strange ASoC volume control. In this case, the values are not in volume order, i e, the control is declared something like below.
However alsamixer seems not to handle this "reordering" correctly. My question is if this is something that should be fixed in alsamixer (or possibly alsa-lib?), or does one need to write some kind of mapping table in the kernel, just to make something come in volume order to userspace?
Items in a DB_RANGE container must be ordered by their values *and* by their dB values. This implies that larger values must correspond with larger dB values, whis is also required for all other mixer controls.
If the register values are unordered, the driver must reorder them.
static const unsigned int tlv[] = { TLV_DB_RANGE_HEAD(8),
This should be rewritten as:
static const DECLARE_TLV_DB_RANGE(tlv, 0, 0, TLV_DB_SCALE_ITEM(-100, 0, 1), ... );
Regards, Clemens
At Wed, 08 May 2013 14:09:31 +0200, Clemens Ladisch wrote:
David Henningsson wrote:
I recently came across a strange ASoC volume control. In this case, the values are not in volume order, i e, the control is declared something like below.
However alsamixer seems not to handle this "reordering" correctly. My question is if this is something that should be fixed in alsamixer (or possibly alsa-lib?), or does one need to write some kind of mapping table in the kernel, just to make something come in volume order to userspace?
Items in a DB_RANGE container must be ordered by their values *and* by their dB values. This implies that larger values must correspond with larger dB values, whis is also required for all other mixer controls.
If the register values are unordered, the driver must reorder them.
Yep. Although there is no explicit definition, it's an implicit rule, as we have never implemented the parser code to allow the disorder.
We should add a text mentioning that somewhere. A patch is welcome ;)
thanks,
Takashi
On 05/08/2013 02:14 PM, Takashi Iwai wrote:
At Wed, 08 May 2013 14:09:31 +0200, Clemens Ladisch wrote:
David Henningsson wrote:
I recently came across a strange ASoC volume control. In this case, the values are not in volume order, i e, the control is declared something like below.
However alsamixer seems not to handle this "reordering" correctly. My question is if this is something that should be fixed in alsamixer (or possibly alsa-lib?), or does one need to write some kind of mapping table in the kernel, just to make something come in volume order to userspace?
Items in a DB_RANGE container must be ordered by their values *and* by their dB values. This implies that larger values must correspond with larger dB values, whis is also required for all other mixer controls.
If the register values are unordered, the driver must reorder them.
Yep. Although there is no explicit definition, it's an implicit rule, as we have never implemented the parser code to allow the disorder.
We should add a text mentioning that somewhere. A patch is welcome ;)
Like this? (Feel free to apply if you think it's good)
At Wed, 08 May 2013 15:33:11 +0200, David Henningsson wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] On 05/08/2013 02:14 PM, Takashi Iwai wrote:
At Wed, 08 May 2013 14:09:31 +0200, Clemens Ladisch wrote:
David Henningsson wrote:
I recently came across a strange ASoC volume control. In this case, the values are not in volume order, i e, the control is declared something like below.
However alsamixer seems not to handle this "reordering" correctly. My question is if this is something that should be fixed in alsamixer (or possibly alsa-lib?), or does one need to write some kind of mapping table in the kernel, just to make something come in volume order to userspace?
Items in a DB_RANGE container must be ordered by their values *and* by their dB values. This implies that larger values must correspond with larger dB values, whis is also required for all other mixer controls.
If the register values are unordered, the driver must reorder them.
Yep. Although there is no explicit definition, it's an implicit rule, as we have never implemented the parser code to allow the disorder.
We should add a text mentioning that somewhere. A patch is welcome ;)
Like this? (Feel free to apply if you think it's good)
Thanks, I applied it with slight modification (align the comment lines).
Takashi
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic [2 0001-ALSA-Add-comment-for-control-TLV-API.patch <text/x-patch (7bit)>]
From 19778a06ef5bd995ba1e800dc14bbe7ff27dcb97 Mon Sep 17 00:00:00 2001
From: David Henningsson david.henningsson@canonical.com Date: Wed, 8 May 2013 15:28:49 +0200 Subject: [PATCH] ALSA: Add comment for control TLV API
Userspace is not meant to have to handle all strange dB ranges, so add a specification comment.
Signed-off-by: David Henningsson david.henningsson@canonical.com
include/sound/tlv.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/sound/tlv.h b/include/sound/tlv.h index 28c65e1..84fc31a 100644 --- a/include/sound/tlv.h +++ b/include/sound/tlv.h @@ -74,7 +74,10 @@ #define DECLARE_TLV_DB_LINEAR(name, min_dB, max_dB) \ unsigned int name[] = { TLV_DB_LINEAR_ITEM(min_dB, max_dB) }
-/* dB range container */ +/* dB range container. Items in dB range container must be ordered +by their values and by their dB values. This implies that larger values +must correspond with larger dB values (which is also required for all +other mixer controls). */ /* Each item is: <min> <max> <TLV> */ #define TLV_DB_RANGE_ITEM(...) \ TLV_ITEM(SNDRV_CTL_TLVT_DB_RANGE, __VA_ARGS__) -- 1.7.9.5
On Wed, May 08, 2013 at 01:21:41PM +0200, David Henningsson wrote:
I recently came across a strange ASoC volume control. In this case, the values are not in volume order, i e, the control is declared something like below. I believe the numbers correctly match the hardware.
Oh, joy. What driver is this?
On 05/09/2013 12:12 PM, Mark Brown wrote:
On Wed, May 08, 2013 at 01:21:41PM +0200, David Henningsson wrote:
I recently came across a strange ASoC volume control. In this case, the values are not in volume order, i e, the control is declared something like below. I believe the numbers correctly match the hardware.
Oh, joy. What driver is this?
I think it's not in the mainline kernel at this point.
participants (4)
-
Clemens Ladisch -
David Henningsson -
Mark Brown -
Takashi Iwai