Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

Heya,

a while back I wrote a little tool "dbmeasure" which can be used to
determine dB attenuation data for alsa mixer controls. I have now
extended this little dB tools suite to include a tiny tool "dbverify"
that can be used to verify the correctness of existing dB data exposed
by the drivers. It should be relatively easy to use that tool,
suitable even for non-guru folks who want to debug the dB information
from alsa.

http://git.0pointer.de/?p=dbmeasure.git
git://git.0pointer.de/dbmeasure.git

Just run "make" in a git checkout and then try:

   $ ./dbverify Aureon51MkII Master 30 200

That will verify the dB data of the "Master" control of the sound card
that goes by the id "Aureon51MkII". It will compare the discrete
volume steps 30 and 200: first it will play a full amplitude sine wave
at mixer volume step 30, and then will change to mixer volume step
200, but attenuate the sine wave in software compensating for the
volume change. So once you hear the sine wave attenuated by the hw,
and once by the software. If the card's dB data is correct both sines
should have the same volume.

Now, playing around with this, I could verify what I already mentioned
to Jarsolav elsewhere earlier: it seems that particularly USB cards
seem to expose invalid dB data (at least all mine do). For example,
for the above mentioned Aureon 5.1 it's really *way* off -- if you
posess that card just run the line above, and listen to the
difference. It's really bad. OTOH the dB data of the HDA cards I own
is pretty accurate as it seems, at least I was unable to decide just
by listening which sine wave was attenuated by sw, and which by hw.

Getting back to the invalid dB data from the USB cards: the question
is whether the USB descriptor data is badly parsed, and the dB
mismatch hence systematic for USB cards, or if these cards are just
crappy and include invalid data? In which case I wonder what we could
do about that? The Aureon's dB range already looks suspicous, since
both the max and the min dB value are < 0 (-47.69 to -1.97), so maybe
we could add some heuristics to filter out data that already looks
suspicous?

Invalid dB data from the driver is a real problem for the "flat
volume" logic in PA. We basically allow each app to control the full
hw volume range individually, and then set the hw volume to the max of
what all apps wanted and attenuate the other streams accordingly. On
the Aureon this doesn't work at all, since the attenuation of the
streams is miscalculated due to the invalid dB data.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Clemens Ladisch]

Lennart Poettering wrote:
> Getting back to the invalid dB data from the USB cards: the question
> is whether the USB descriptor data is badly parsed, and the dB
> mismatch hence systematic for USB cards,

USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB.
When the level is computed from the minimum plus a multiple of the step
size, rounding errors add up considerately.

ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the
range with the min/max values to minimize those rounding errors.


Regards,
Clemens

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Tue, 16 Feb 2010, Clemens Ladisch wrote:

> Lennart Poettering wrote:
>> Getting back to the invalid dB data from the USB cards: the question
>> is whether the USB descriptor data is badly parsed, and the dB
>> mismatch hence systematic for USB cards,
>
> USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB.
> When the level is computed from the minimum plus a multiple of the step
> size, rounding errors add up considerately.
>
> ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the
> range with the min/max values to minimize those rounding errors.

Unfortunately, it's not the case of a rounding problem. The USB 
specification is too much vague and vendors don't use the dB range 
correctly. For example, I tested SB MP3+ USB device and reported ranges 
were:

Master: -47.87dB..0.06dB	# correct
Line: 0dB..47.81dB		# seems correct -47.81dB..0dB
Line Capture: -0.18dB..23.81dB	# seems correct -17.81dB..6.18dB

I just did tests using another soundcard to generate sounds and 
played back the captured result to determine the gain in the capture 
direction.

I put my results to:

http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=c3a3e040f01457d2ea4f199f75ca205401001a3b

The SB MP3+ uses AC97 codec AD1995 with some own ASIC from Creative. So I 
think that even the 47.87 values are not correct and the real ranges are
from -48dB..0dB and -18dB..6dB.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Mon, 15 Feb 2010, Lennart Poettering wrote:

> Heya,
>
> a while back I wrote a little tool "dbmeasure" which can be used to
> determine dB attenuation data for alsa mixer controls. I have now
> extended this little dB tools suite to include a tiny tool "dbverify"
> that can be used to verify the correctness of existing dB data exposed
> by the drivers. It should be relatively easy to use that tool,
> suitable even for non-guru folks who want to debug the dB information
> from alsa.
>
> http://git.0pointer.de/?p=dbmeasure.git
> git://git.0pointer.de/dbmeasure.git

Thank you for this code. I'm playing with an idea to start gathering of 
all ALSA tests around and make a GUI for them. But it might make sense to 
use something more portable than C language and use standard ALSA tools 
(amixer, aplay) as backends ;-)

For USB cards, the dB ranges read from hw are not correct. We have to 
overwrite these bad values in the driver. Unfortunately, the USB driver 
doesn't show the USB descriptor -> ALSA control mapping to gather all 
necessary information for the code updates. I'm working on a patch right 
now to obtain this information using procfs.

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Tue, 16 Feb 2010, Jaroslav Kysela wrote:

> On Mon, 15 Feb 2010, Lennart Poettering wrote:
>
>> Heya,
>> 
>> a while back I wrote a little tool "dbmeasure" which can be used to
>> determine dB attenuation data for alsa mixer controls. I have now
>> extended this little dB tools suite to include a tiny tool "dbverify"
>> that can be used to verify the correctness of existing dB data exposed
>> by the drivers. It should be relatively easy to use that tool,
>> suitable even for non-guru folks who want to debug the dB information
>> from alsa.
>> 
>> http://git.0pointer.de/?p=dbmeasure.git
>> git://git.0pointer.de/dbmeasure.git
>
> Thank you for this code. I'm playing with an idea to start gathering of all 
> ALSA tests around and make a GUI for them. But it might make sense to use 
> something more portable than C language and use standard ALSA tools (amixer, 
> aplay) as backends ;-)
>
> For USB cards, the dB ranges read from hw are not correct. We have to 
> overwrite these bad values in the driver. Unfortunately, the USB driver 
> doesn't show the USB descriptor -> ALSA control mapping to gather all 
> necessary information for the code updates. I'm working on a patch right now 
> to obtain this information using procfs.

The patch is available here:

http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=6daf48108cb0136b762998bb5c2b0b32234b4e93

I also updated the alsa-info.sh script to gather this information.

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Tue, 16.02.10 09:08, Clemens Ladisch (clemens@ladisch.de) wrote:

> 
> Lennart Poettering wrote:
> > Getting back to the invalid dB data from the USB cards: the question
> > is whether the USB descriptor data is badly parsed, and the dB
> > mismatch hence systematic for USB cards,
> 
> USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB.
> When the level is computed from the minimum plus a multiple of the step
> size, rounding errors add up considerately.
> 
> ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the
> range with the min/max values to minimize those rounding errors.

I am really sure that the discrepancy I measure with the Aureon is way
beyond rounding errors.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:

> > ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the
> > range with the min/max values to minimize those rounding errors.
> 
> Unfortunately, it's not the case of a rounding problem. The USB 
> specification is too much vague and vendors don't use the dB range 
> correctly. For example, I tested SB MP3+ USB device and reported ranges 
> were:
> 
> Master: -47.87dB..0.06dB	# correct
> Line: 0dB..47.81dB		# seems correct -47.81dB..0dB
> Line Capture: -0.18dB..23.81dB	# seems correct
> -17.81dB..6.18dB

Hmm, how did you choose where to put 0dB?

> http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=c3a3e040f01457d2ea4f199f75ca205401001a3b
> 
> The SB MP3+ uses AC97 codec AD1995 with some own ASIC from Creative. So I 
> think that even the 47.87 values are not correct and the real ranges are
> from -48dB..0dB and -18dB..6dB.

So if I understand this correctly, then the way to handle issues like
this is to measure the dB data for each USB card in question and then
update the drivers with quirks accordingly? 

So if I want my Aureon to work properly I better start measuring now?

Would it be feasible to allow overriding of the dB data from
userspace, i.e. from the alsa mixer init db perhaps?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
> On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:

> > Line: 0dB..47.81dB		# seems correct -47.81dB..0dB
> > Line Capture: -0.18dB..23.81dB	# seems correct
> > -17.81dB..6.18dB

> Hmm, how did you choose where to put 0dB?

The Line one looks like someone got attenuation and gain confused, which
is a fairly common mistake for people to make when copying information
from one place to another.  Possibly a similar thing going on with the
Line Capture control, plus a fixed 6dB gain (which may well be a
separate amp...).

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Tue, 16.02.10 14:40, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:

> 
> On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
> > On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
> 
> > > Line: 0dB..47.81dB		# seems correct -47.81dB..0dB
> > > Line Capture: -0.18dB..23.81dB	# seems correct
> > > -17.81dB..6.18dB
> 
> > Hmm, how did you choose where to put 0dB?
> 
> The Line one looks like someone got attenuation and gain confused, which
> is a fairly common mistake for people to make when copying information
> from one place to another.  Possibly a similar thing going on with the
> Line Capture control, plus a fixed 6dB gain (which may well be a
> separate amp...).

I remember that a while back we had a discussion on alsa-devel
regarding the fact that ALSA does not define relative to what the dB
values reported by the mixer elements actually are measured. Some
mixer controls export dB values relative to max amplification (e.g. my
integrated USB speakers here), others relative to the output of some
other mixer element, and others relative to different standard or
not-so-standard output voltages.  And there is no API to figure out
what the base is.

Now, what Jaroslav listed above suggests that he chose carefully where
he put 0dB. I was just wondering about that. Jaroslav, how did you
choose where to put 0dB?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Tue, Feb 16, 2010 at 04:40:16PM +0100, Lennart Poettering wrote:

> Now, what Jaroslav listed above suggests that he chose carefully where
> he put 0dB. I was just wondering about that. Jaroslav, how did you
> choose where to put 0dB?

FWIW all the drivers I do take whatever the datasheet says the
gain/attenuation range is for the control in question.  For most modern
embedded CODECs there will be multiple user controllable gains in the
path.

We really need to get an API for exposing path information to userspace
to fully describe what's going on here.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Tue, 16 Feb 2010, Lennart Poettering wrote:

> On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
>
>>> ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the
>>> range with the min/max values to minimize those rounding errors.
>>
>> Unfortunately, it's not the case of a rounding problem. The USB
>> specification is too much vague and vendors don't use the dB range
>> correctly. For example, I tested SB MP3+ USB device and reported ranges
>> were:
>>
>> Master: -47.87dB..0.06dB	# correct
>> Line: 0dB..47.81dB		# seems correct -47.81dB..0dB
>> Line Capture: -0.18dB..23.81dB	# seems correct
>> -17.81dB..6.18dB
>
> Hmm, how did you choose where to put 0dB?

It's just tested against another hw using one headphones.

>> http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=c3a3e040f01457d2ea4f199f75ca205401001a3b
>>
>> The SB MP3+ uses AC97 codec AD1995 with some own ASIC from Creative. So I
>> think that even the 47.87 values are not correct and the real ranges are
>> from -48dB..0dB and -18dB..6dB.
>
> So if I understand this correctly, then the way to handle issues like
> this is to measure the dB data for each USB card in question and then
> update the drivers with quirks accordingly?

Basically, yes, these values should be corrected early as possible.

> So if I want my Aureon to work properly I better start measuring now?
>
> Would it be feasible to allow overriding of the dB data from
> userspace, i.e. from the alsa mixer init db perhaps?

It's another possibility. But the right place to handle this issue is 
alsa-lib and parsing a text file with the new data.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Tue, 16 Feb 2010, Lennart Poettering wrote:

> On Tue, 16.02.10 14:40, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
>
>>
>> On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
>>> On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
>>
>>>> Line: 0dB..47.81dB		# seems correct -47.81dB..0dB
>>>> Line Capture: -0.18dB..23.81dB	# seems correct
>>>> -17.81dB..6.18dB
>>
>>> Hmm, how did you choose where to put 0dB?
>>
>> The Line one looks like someone got attenuation and gain confused, which
>> is a fairly common mistake for people to make when copying information
>> from one place to another.  Possibly a similar thing going on with the
>> Line Capture control, plus a fixed 6dB gain (which may well be a
>> separate amp...).
>
> I remember that a while back we had a discussion on alsa-devel
> regarding the fact that ALSA does not define relative to what the dB
> values reported by the mixer elements actually are measured. Some
> mixer controls export dB values relative to max amplification (e.g. my
> integrated USB speakers here), others relative to the output of some
> other mixer element, and others relative to different standard or
> not-so-standard output voltages.  And there is no API to figure out
> what the base is.
>
> Now, what Jaroslav listed above suggests that he chose carefully where
> he put 0dB. I was just wondering about that. Jaroslav, how did you
> choose where to put 0dB?

Basically, if I remember correctly the discussion, 0dB on all elements 
should main unchanged volume, <0dB attenuation and >0dB gain. We cannot 
measure precisely other components on path like analog volume wheels 
(like SB MP3+ has to change line-out volume), analog amplifiers and other 
analog signal modificators.

So, if you use one headphones and speakers with defined and fixed volume 
settings, you can measure differences for the card with broken dB volume 
ranges. I just used another HDA card in notebook with 0dB settings on all 
playback controls on path, captured stream from this card on my USB card 
and played this stream back on my USB card watching and relating the 
volume levels according dB values. It's not 100% correct, but at least 
it's something to start with.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Tue, 16.02.10 17:29, Jaroslav Kysela (perex@perex.cz) wrote:

> > I remember that a while back we had a discussion on alsa-devel
> > regarding the fact that ALSA does not define relative to what the dB
> > values reported by the mixer elements actually are measured. Some
> > mixer controls export dB values relative to max amplification (e.g. my
> > integrated USB speakers here), others relative to the output of some
> > other mixer element, and others relative to different standard or
> > not-so-standard output voltages.  And there is no API to figure out
> > what the base is.
> >
> > Now, what Jaroslav listed above suggests that he chose carefully where
> > he put 0dB. I was just wondering about that. Jaroslav, how did you
> > choose where to put 0dB?
> 
> Basically, if I remember correctly the discussion, 0dB on all elements 
> should main unchanged volume, <0dB attenuation and >0dB gain.

But you need some kind of "anchor" for that. What you write above
applies only for elements that have some kind of analog input and
output. But the most interesting components are probably the DAC and
ADC (i.e. the "innermost" elements), and it's not clear what level they
output, so the "anchor" for the relative dB values is missing...

> So, if you use one headphones and speakers with defined and fixed volume 
> settings, you can measure differences for the card with broken dB volume 
> ranges. I just used another HDA card in notebook with 0dB settings on all 
> playback controls on path, captured stream from this card on my USB card 
> and played this stream back on my USB card watching and relating the 
> volume levels according dB values. It's not 100% correct, but at least 
> it's something to start with.

Hmm, so you basically tuned the USB card's DAC/ADC level to the HDA
card's DAC/ADC.

I now measured the "Master" slider of my aureon (USB 0ccd:0028,
TerraTec Aureon 5.1 MkII) with the aforementioned dbmeasure tool and a
loopback cable. The aureon has 65536 volume steps, but
I was too lazy to measure them all. So I only measured every
3000th. From the max volume to the min volume:

65536 0 dB
62536 0.00560039 dB
59536 0.00694678 dB
56536 0.00616732 dB
53536 0.00645077 dB
50536 0.00673421 dB
47536 -1.49514 dB
44536 -1.49455 dB
41536 -1.49648 dB
38536 -2.98666 dB
35536 -2.98486 dB
32536 -2.98536 dB
29536 -4.48688 dB
26536 -6.00084 dB
23536 -5.99928 dB
20536 -9.00246 dB
17536 -10.5425 dB
14536 -16.5274 dB
11536 -32.9435 dB
8536 -43.4326 dB
5536 -43.5066 dB
2536 -43.2968 dB
0 -43.4431 dB

If you plot this it looks as if the card actually only implements 10
or so discrete steps, and at around 10000 just becomes a constant
function.

ALSA reports -47.87 .. -1.97 for this. So it seems the overall range
the USB data reports is not really that far off, but the volume
function in bteween is.

The noise level of these measurements is < -58 dB.

What's the next step with this measurement data? Will you take it from
here, or shall I provide you with more data?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[James Courtier-Dutton]

On 16 February 2010 15:40, Lennart Poettering <mznyfn@0pointer.de> wrote:
>
> I remember that a while back we had a discussion on alsa-devel
> regarding the fact that ALSA does not define relative to what the dB
> values reported by the mixer elements actually are measured. Some
> mixer controls export dB values relative to max amplification (e.g. my
> integrated USB speakers here), others relative to the output of some
> other mixer element, and others relative to different standard or
> not-so-standard output voltages.  And there is no API to figure out
> what the base is.
>
> Now, what Jaroslav listed above suggests that he chose carefully where
> he put 0dB. I was just wondering about that. Jaroslav, how did you
> choose where to put 0dB?
>

I think what you are trying to do is actually quite difficult.
The rules are very simple for digital controls. At 0dB the gain is 0
and the attenuation is 0 so the value going into the control will be
identical to the value after the control.
The trouble starts at the analogue stages.
First we would want to decide on what output we actually want.
I think this would depend on the sound card itself. Pro sound cards
can output a different set of levels than consumer sound cards.
I think the only way to fix the current problem is to determine a
sound card that has the correct levels and controls, and then
calibrate other sound cards from that.
It will take a long time.
Up until now, the best we have been able to do is read data sheets and
use the values form the data sheets.

I guess a good start would be what digital values should create what
voltages on the line output?
One can then at least get the 0dB point set right.

Kind Regards

James

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Tue, Feb 16, 2010 at 10:07:03PM +0100, Lennart Poettering wrote:
> On Tue, 16.02.10 17:29, Jaroslav Kysela (perex@perex.cz) wrote:

> > Basically, if I remember correctly the discussion, 0dB on all elements 
> > should main unchanged volume, <0dB attenuation and >0dB gain.

> But you need some kind of "anchor" for that. What you write above
> applies only for elements that have some kind of analog input and
> output. But the most interesting components are probably the DAC and
> ADC (i.e. the "innermost" elements), and it's not clear what level they
> output, so the "anchor" for the relative dB values is missing...

Typically the DACs and ADCs will have a full scale signal at line
reference level - it should generally be a good approximation with
nothing else to go on.

> If you plot this it looks as if the card actually only implements 10
> or so discrete steps, and at around 10000 just becomes a constant
> function.

That's quite common.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Tue, 16.02.10 22:39, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:

> 
> On Tue, Feb 16, 2010 at 10:07:03PM +0100, Lennart Poettering wrote:
> > On Tue, 16.02.10 17:29, Jaroslav Kysela (perex@perex.cz) wrote:
> 
> > > Basically, if I remember correctly the discussion, 0dB on all elements 
> > > should main unchanged volume, <0dB attenuation and >0dB gain.
> 
> > But you need some kind of "anchor" for that. What you write above
> > applies only for elements that have some kind of analog input and
> > output. But the most interesting components are probably the DAC and
> > ADC (i.e. the "innermost" elements), and it's not clear what level they
> > output, so the "anchor" for the relative dB values is missing...
> 
> Typically the DACs and ADCs will have a full scale signal at line
> reference level - it should generally be a good approximation with
> nothing else to go on.

"line reference level"? What is that?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Tue, Feb 16, 2010 at 11:42:12PM +0100, Lennart Poettering wrote:
> On Tue, 16.02.10 22:39, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:

> > Typically the DACs and ADCs will have a full scale signal at line
> > reference level - it should generally be a good approximation with
> > nothing else to go on.

> "line reference level"? What is that?

As I understand it (and bear in mind that I'm a software rather than
electrical engineer) it's not 100% fixed, though since the actual result
depends very much on what it's connected to an absolute answer isn't as
important as it might be.  1V RMS is very standard in consumer stuff at
least.

If you could frame exactly the information that you're looking for then
I should be able to ask a few people who are electrical engineers and
get a more coherent answer for you.   I guess you're looking at trying
to have PulseAudio set sensible levels by default?

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Eliot Blennerhassett]

Lennart Poettering wrote:
> On Tue, 16.02.10 22:39, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
> 
>> On Tue, Feb 16, 2010 at 10:07:03PM +0100, Lennart Poettering wrote:
>>> On Tue, 16.02.10 17:29, Jaroslav Kysela (perex@perex.cz) wrote:
>>>> Basically, if I remember correctly the discussion, 0dB on all elements 
>>>> should main unchanged volume, <0dB attenuation and >0dB gain.
>>> But you need some kind of "anchor" for that. What you write above
>>> applies only for elements that have some kind of analog input and
>>> output. But the most interesting components are probably the DAC and
>>> ADC (i.e. the "innermost" elements), and it's not clear what level they
>>> output, so the "anchor" for the relative dB values is missing...
>> Typically the DACs and ADCs will have a full scale signal at line
>> reference level - it should generally be a good approximation with
>> nothing else to go on.
> 
> "line reference level"? What is that?
> 
> Lennart
> 

There are two separate issues here.
1) Incorrect dB<->linear mapping
ALSA Volume/Gain controls returning incorrect information about mapping
from linear values to dB.  E.g. adding "6dB" to the Volume controls
while subtracting 6dB in software does not result in 0dB overall gain.

For volume controls the convention is  0dB == multiply by 1.0 == no
change. Any sane digital volume control should obey this.
For analog volumes, the 0dB position is entirely arbtrary, as I discuss
below.

2) Absolute calibration of output levels.
(This is *not* required to solve Lennart's problem)
This would be required if you wanted two different (brands of) soundcard
to output the same voltage for given source pcm.

>From the perspective of a Pro audio card maker, we have another kind of
control at the analog terminals of the card. This is the Level control,
and it specifies the absolute voltage at the output for full scale
digital signal (and intermediate Volumes set to 0dB)

It has units of dBu http://en.wikipedia.org/wiki/Decibel#Voltage.
(It might as well be dBV or any other reference dB measurement).

For our cards this is adjustable, but lets say for consumer cards it is
fixed.  This information is not currently available via the ALSA API.

A hypothetical example.
[DAC>---[Variable gain>---[amplifier>---[output jack]

Lets say
the DAC produces 2Vpp (6dBVpp) for fullscale digital input (0dBFS)
and the amplifier has 6dB gain.
and the variable gain is from -40dB to 0dB
and the units of the reference level are dBVpp

Combining these we represent the DAC + gain + amplifier as a single
Level control with units of dBVpp and range -28dBVpp to +12dBVpp

or equally valid, could represent it as
a Volume with range -40dB to 0dB followed by a
a fixed level of +12dBVpp

or equally valid, could represent it as
a Volume with range 0dB to +40dB followed by a
a fixed level of -28dBVpp

i.e. the 0dB position is arbitrary, related to what is chosen as the
output reference level.

The fixed level information, would be attached to some representation of
the output connector.

Clear as mud?

regards

Eliot Blennerhassett
http://www.audioscience.com

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Tue, 16.02.10 23:38, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:

> 
> On Tue, Feb 16, 2010 at 11:42:12PM +0100, Lennart Poettering wrote:
> > On Tue, 16.02.10 22:39, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
> 
> > > Typically the DACs and ADCs will have a full scale signal at line
> > > reference level - it should generally be a good approximation with
> > > nothing else to go on.
> 
> > "line reference level"? What is that?
> 
> As I understand it (and bear in mind that I'm a software rather than
> electrical engineer) it's not 100% fixed, though since the actual result
> depends very much on what it's connected to an absolute answer isn't as
> important as it might be.  1V RMS is very standard in consumer stuff at
> least.
> 
> If you could frame exactly the information that you're looking for then
> I should be able to ask a few people who are electrical engineers and
> get a more coherent answer for you.   I guess you're looking at trying
> to have PulseAudio set sensible levels by default?

Nah. I actually don't need this value for PulseAudio. In PulseAudio I
chose to shift all scales so that maximum amplification becomes 0 dB,
so that the UIs are similar to how most hifi racks do it, and which I
think is a nice, easy and understandable logic. That way my volume
scales range from -inf dB to 0 dB in all cases, regardless of the
hardware/drivers in use. Of course, that means that ALSA's own 0dB is
not directly visible on the scale. Because it might be sometimes
useful to know where it is, we export that position as "base volume"
and the UIs show it with a little marker at the side.

The reason I was asking how Jaroslav chose the 0dB position for his
measurements was purely because I wanted to do my own measurements for
that Aureon card. The dbmeasure tool I wrote for stuff like that puts
0dB at max amplification, however Jaroslav didn't, so I was wondering
how he chose 0dB then.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Wed, 17.02.10 12:47, Eliot Blennerhassett (linux@audioscience.com) wrote:

> For our cards this is adjustable, but lets say for consumer cards it is
> fixed.  This information is not currently available via the ALSA
> API.

I wonder how realistic it would even be to add an API for
this. i.e. can we even know the refernce level? On many cards most
likely not. For example, for my integrated USB speakers speaking of a
reference voltage would already be misleading...

> A hypothetical example.
> [DAC>---[Variable gain>---[amplifier>---[output jack]
> 
> Lets say
> the DAC produces 2Vpp (6dBVpp) for fullscale digital input (0dBFS)
> and the amplifier has 6dB gain.
> and the variable gain is from -40dB to 0dB
> and the units of the reference level are dBVpp
> 
> Combining these we represent the DAC + gain + amplifier as a single
> Level control with units of dBVpp and range -28dBVpp to +12dBVpp
> 
> or equally valid, could represent it as
> a Volume with range -40dB to 0dB followed by a
> a fixed level of +12dBVpp
> 
> or equally valid, could represent it as
> a Volume with range 0dB to +40dB followed by a
> a fixed level of -28dBVpp
> 
> i.e. the 0dB position is arbitrary, related to what is chosen as the
> output reference level.

Yepp, that's the exactly what I was asking, Jaroslav's measurements
suggested to shift one of the mixer controls from 0..x dB to -x..0 dB
and I was just wondering why, since we don't define the ref level in
ALSA, hence the shift is kinda arbitrary...

Anyway, I am not pushing for adding an API for reference levels to
ALSA. As mentioned for the PA case I decided to shift 0dB to max
amplification in any case, which I think is a workable way to avoid
this problem.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Wed, Feb 17, 2010 at 01:10:47AM +0100, Lennart Poettering wrote:
> On Wed, 17.02.10 12:47, Eliot Blennerhassett (linux@audioscience.com) wrote:

> > For our cards this is adjustable, but lets say for consumer cards it is
> > fixed.  This information is not currently available via the ALSA
> > API.

> I wonder how realistic it would even be to add an API for
> this. i.e. can we even know the refernce level? On many cards most
> likely not. For example, for my integrated USB speakers speaking of a
> reference voltage would already be misleading...

Like you say even where we know the actual level it's not practically
useful unless it's physically exposed somewhere the user can see it.

For things like line jacks where it is relevant these things do actually
get documented relatively often, and obviously measurements are possible
where they aren't.  I'm not sure how interesting it is unless the system
also supports configuration, though.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Eliot Blennerhassett]

Lennart Poettering wrote:
> On Wed, 17.02.10 12:47, Eliot Blennerhassett (linux@audioscience.com) wrote:
> 
>> For our cards this is adjustable, but lets say for consumer cards it is
>> fixed.  This information is not currently available via the ALSA
>> API.
> 
> I wonder how realistic it would even be to add an API for
> this. i.e. can we even know the refernce level? On many cards most
> likely not. For example, for my integrated USB speakers speaking of a
> reference voltage would already be misleading...

Certainly. Same for laptop speakers.

Perhaps could define 0dB as the highest valid volume setting that
doesn't cause distortion in the audio when playing a full scale digital
signal.

Otherwise the absolute reference might be dBSPL at X metres from the
speaker ;)  (before anyone answers - in this context I'm joking.)

> Yepp, that's the exactly what I was asking, Jaroslav's measurements
> suggested to shift one of the mixer controls from 0..x dB to -x..0 dB
> and I was just wondering why, since we don't define the ref level in
> ALSA, hence the shift is kinda arbitrary...
> 
> Anyway, I am not pushing for adding an API for reference levels to
> ALSA. 

We define controls with names like "LineIn0 Level","LineOut1 Level"
which we document as having units of dBu.

Given that no other driver has this, its the de-facto standard ;)

> As mentioned for the PA case I decided to shift 0dB to max
> amplification in any case, which I think is a workable way to avoid
> this problem.

Sure.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/16 Lennart Poettering <mznyfn@0pointer.de>

> On Tue, 16.02.10 09:08, Clemens Ladisch (clemens@ladisch.de) wrote:
>
> >
> > Lennart Poettering wrote:
> > > Getting back to the invalid dB data from the USB cards: the question
> > > is whether the USB descriptor data is badly parsed, and the dB
> > > mismatch hence systematic for USB cards,
> >
> > USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB.
> > When the level is computed from the minimum plus a multiple of the step
> > size, rounding errors add up considerately.
> >
> > ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the
> > range with the min/max values to minimize those rounding errors.
>
> I am really sure that the discrepancy I measure with the Aureon is way
> beyond rounding errors.
>
> Lennart
>
>
if the program use a format FLOAT_LE  which is not supported by the hardware
and need to use plughw , you have already added error ( resampling and
format conversion ) to the result

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/16 Lennart Poettering <mznyfn@0pointer.de>

> Heya,
>
> a while back I wrote a little tool "dbmeasure" which can be used to
> determine dB attenuation data for alsa mixer controls. I have now
> extended this little dB tools suite to include a tiny tool "dbverify"
> that can be used to verify the correctness of existing dB data exposed
> by the drivers. It should be relatively easy to use that tool,
> suitable even for non-guru folks who want to debug the dB information
> from alsa.
>
> http://git.0pointer.de/?p=dbmeasure.git
> git://git.0pointer.de/dbmeasure.git
>
> Just run "make" in a git checkout and then try:
>
>   $ ./dbverify Aureon51MkII Master 30 200
>
> That will verify the dB data of the "Master" control of the sound card
> that goes by the id "Aureon51MkII". It will compare the discrete
> volume steps 30 and 200: first it will play a full amplitude sine wave
> at mixer volume step 30, and then will change to mixer volume step
> 200, but attenuate the sine wave in software compensating for the
> volume change. So once you hear the sine wave attenuated by the hw,
> and once by the software. If the card's dB data is correct both sines
> should have the same volume.
>
> Now, playing around with this, I could verify what I already mentioned
> to Jarsolav elsewhere earlier: it seems that particularly USB cards
> seem to expose invalid dB data (at least all mine do). For example,
> for the above mentioned Aureon 5.1 it's really *way* off -- if you
> posess that card just run the line above, and listen to the
> difference. It's really bad. OTOH the dB data of the HDA cards I own
> is pretty accurate as it seems, at least I was unable to decide just
> by listening which sine wave was attenuated by sw, and which by hw.
>
> Getting back to the invalid dB data from the USB cards: the question
> is whether the USB descriptor data is badly parsed, and the dB
> mismatch hence systematic for USB cards, or if these cards are just
> crappy and include invalid data? In which case I wonder what we could
> do about that? The Aureon's dB range already looks suspicous, since
> both the max and the min dB value are < 0 (-47.69 to -1.97), so maybe
> we could add some heuristics to filter out data that already looks
> suspicous?
>
> Invalid dB data from the driver is a real problem for the "flat
> volume" logic in PA. We basically allow each app to control the full
> hw volume range individually, and then set the hw volume to the max of
> what all apps wanted and attenuate the other streams accordingly. On
> the Aureon this doesn't work at all, since the attenuation of the
> streams is miscalculated due to the invalid dB data.
>
> Lennart
>
>
Refer to README

WHAT YOU NEED?

         a) A sound card where input and output are synchronous
         b) A feedback cable that allows you to feed sound card output


how do I know my sound card support synchronous playback and  capture ?

do you program able to find out whether the sound card support synchronous
playback and  capture ?

do your result still valid if the sound card does not support synchronous
playback and  capture ?

do the result different if I use analog loop back of the ac97 codec instead
of a loop back cable ?

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 Eliot Blennerhassett <linux@audioscience.com>

> >
>
> There are two separate issues here.
> 1) Incorrect dB<->linear mapping
> ALSA Volume/Gain controls returning incorrect information about mapping
> from linear values to dB.  E.g. adding "6dB" to the Volume controls
> while subtracting 6dB in software does not result in 0dB overall gain.
>
> For volume controls the convention is  0dB == multiply by 1.0 == no
> change. Any sane digital volume control should obey this.
> For analog volumes, the 0dB position is entirely arbtrary, as I discuss
> below.
>
>
For the alsa db values are in step of  1.5 dB or 3.dB ,

but the software shift one bit is 10 log 2 = 3.0102996* dB

*
That 's why adding "6dB" to the Volume controls
while subtracting 6dB in software does not result in 0dB overall gain.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Tue, 16 Feb 2010, James Courtier-Dutton wrote:

> I guess a good start would be what digital values should create what
> voltages on the line output?
> One can then at least get the 0dB point set right.

It seems that I have to buy a precise voltmeter or good digital 
oscilloscope to get these results :-) Anyway, the voltage levels 
expressions are described nicely here:

http://en.wikipedia.org/wiki/Decibel

>From above pro-equipment works with 0.775V as reference volume (0dBu) 
and consumer electronics with 1V as reference volume (0dBV).

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Wed, 17 Feb 2010, Lennart Poettering wrote:

> Yepp, that's the exactly what I was asking, Jaroslav's measurements
> suggested to shift one of the mixer controls from 0..x dB to -x..0 dB
> and I was just wondering why, since we don't define the ref level in
> ALSA, hence the shift is kinda arbitrary...

I think that having a reference level is good for users. For example, 
some AC97 codecs have Line Out range from -94.5dB .. 0dB , Mixed Line In 
is in range -34.5dB .. 12dB. So if I set 0dB to Line In and 0dB to Line 
Out, I would expect to get (if analog parts of soundcard are not 
assymetric) identical output level as input level.

For USB card as I mentioned, I got Line Out from range -48dB..0dB and Line 
In in 0dB..48dB. I would assume from the first look to the alsamixer 
volume bars that the Line In gain is too much.

It's about consistency for users. Rule <0dB attenuation >0dB gain matches 
this criterium.

The second question is if the represented dB range and scale reported from 
the driver (hardware and audio chip datasheets) really matches the 
hardware and how we can measure these values. I suspect a lot of trouble 
here, because the analog parts of soundcards might have strange curves - 
it's probably thing you deal with in PA now.

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Wed, Feb 17, 2010 at 12:56:58AM +0100, Lennart Poettering wrote:

> Nah. I actually don't need this value for PulseAudio. In PulseAudio I
> chose to shift all scales so that maximum amplification becomes 0 dB,
> so that the UIs are similar to how most hifi racks do it, and which I

Interesting.  The hifi equipment I've dealt with typically doesn't
present any units at all in the UI outside of level monitors.

> think is a nice, easy and understandable logic. That way my volume
> scales range from -inf dB to 0 dB in all cases, regardless of the
> hardware/drivers in use. Of course, that means that ALSA's own 0dB is
> not directly visible on the scale. Because it might be sometimes
> useful to know where it is, we export that position as "base volume"
> and the UIs show it with a little marker at the side.

Yeah, the actual zero point is definitely needed - it gives an
indication of the expected output level which is very useful during
setup.

I really do need to find time to dig into this code at some point -
there's also the digital vs. analogue gain thing I've mentioned to you
before that I wanted to look at.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Wed, Feb 17, 2010 at 01:52:11PM +1300, Eliot Blennerhassett wrote:
> Lennart Poettering wrote:

> > I wonder how realistic it would even be to add an API for
> > this. i.e. can we even know the refernce level? On many cards most
> > likely not. For example, for my integrated USB speakers speaking of a
> > reference voltage would already be misleading...

> Certainly. Same for laptop speakers.

> Perhaps could define 0dB as the highest valid volume setting that
> doesn't cause distortion in the audio when playing a full scale digital
> signal.

I think it's something we can leave to be specified for a given bit of
hardware - the absolute level doesn't really mean a huge amount unless
the user is actually interacting it in some way and going with the
reference level that the hardware is using internally means that we get
an idea of how much the control is affecting the signal, which is useful
for getting an idea of the optimal level to set a given control to
(generally the specified 0dB will give the lowest noise, particularly
for amplification).

It's when the signal is being presented in a fashion which means it
might have to be matched with that on another device that the absolute
levels become interesting.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[James Courtier-Dutton]

On 16 February 2010 23:56, Lennart Poettering <mznyfn@0pointer.de> wrote:
>
> The reason I was asking how Jaroslav chose the 0dB position for his
> measurements was purely because I wanted to do my own measurements for
> that Aureon card. The dbmeasure tool I wrote for stuff like that puts
> 0dB at max amplification, however Jaroslav didn't, so I was wondering
> how he chose 0dB then.
>
> Lennart
>

I think the digital side is clear. So I will not go into that.

I think we need to separate the analogue side into a number of categories:
1) Standard consumer line-out levels.
2) Standard pro line-out levels.
3) Consumer line-in levels.
4) Pro line-in levels.
5) Consumer mic levels.
6) Pro mic levels.
7) Consumer speaker levels.
8) Pro speaker levels.

On the analogue side, I believe the 0dB gain point is intended to be
the point at which one can be fairly sure that the distortion will be
low for a sensible full scale input.
I think we can get better definition on items 1 to 4.
To this end, I think ALSA needs a new control type so the user can set
what line out voltages will occur using standard full scale digital
inputs.
http://en.wikipedia.org/wiki/Decibel
>From above pro-equipment works with 0.775V as reference volume (0dBu)
and consumer electronics with 1V as reference volume (0dBV).

So, the new level control types will show dBu and dBV. The current
"gain" controls will show dB.

I think we should focus on items 1 to 4 first, and then sort out 5 to 8 later.
Measurement should be with a volt meter if possible, but we will have
to get the correct output frequency right to match what the volt meter
is expecting, otherwise the readings will be wrong.
We could even be more specific. If we can get items 1 and 2 correct
for all sound cards, we can then more easily calibrate 3 and 4.
Considering that there are over 1000 different sound card variants out
there, this is going to take a long long time.

Kind Regards

James

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Wed, Feb 17, 2010 at 10:04:50AM +0100, Jaroslav Kysela wrote:

> I think that having a reference level is good for users. For example,
> some AC97 codecs have Line Out range from -94.5dB .. 0dB , Mixed Line In
> is in range -34.5dB .. 12dB. So if I set 0dB to Line In and 0dB to Line
> Out, I would expect to get (if analog parts of soundcard are not
> assymetric) identical output level as input level.

That'll tend to be the case for most hardware - the main issues are the
fact that we don't currently have a way to tell userspace about the
signal path in the device (so knowing which amplifiers are in use at a
given time can be tricky) and the fact that you're likely to run into
are that you do get fixed gain or attenuation stages in the signal path
for various reasons and those currently aren't exposed to user space at
all (but that'd probably flop out of doing the routing information).

> The second question is if the represented dB range and scale reported from 
> the driver (hardware and audio chip datasheets) really matches the 
> hardware and how we can measure these values. I suspect a lot of trouble 
> here, because the analog parts of soundcards might have strange curves - 
> it's probably thing you deal with in PA now.

Datasheets really should be reliable, and if the curve in the datsheet
is too unusual to handle with a range the TLV data format does always
allow us to specify subranges (down to individual values for each step)
so there's no fundamental problem exposing the information to user
space.

I'd actually be surprised if there were too much of an issue with this
beyond the data collection one (especially for USB devices).

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Wed, 17.02.10 11:44, Raymond Yau (superquad.vortex2@gmail.com) wrote:

> WHAT YOU NEED?
> 
>          a) A sound card where input and output are synchronous
>          b) A feedback cable that allows you to feed sound card output
> 
> 
> how do I know my sound card support synchronous playback and
> capture ?

We had a discussion about that on alsa-devel a month back or so. The
conclusion was basically that software may assume that playback and
capturing on the same card is clocked the same way and that is all
this tool needs.

> do you program able to find out whether the sound card support synchronous
> playback and  capture ?

No.

> do your result still valid if the sound card does not support synchronous
> playback and  capture ?

It's fine if there is a constant phase shift between what you play
back and record. What matters is that the clock of playback and clock
of capture have the same speed. The tool will sum up a recorded sample
window a couple of times to reduce the noise level below some
threshold, and for that to work we need to make sure that our sine
wave isn't shifted each time we sum it up.

> do the result different if I use analog loop back of the ac97 codec instead
> of a loop back cable ?

Presumably.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Wed, 17.02.10 11:17, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:

> 
> On Wed, Feb 17, 2010 at 12:56:58AM +0100, Lennart Poettering wrote:
> 
> > Nah. I actually don't need this value for PulseAudio. In PulseAudio I
> > chose to shift all scales so that maximum amplification becomes 0 dB,
> > so that the UIs are similar to how most hifi racks do it, and which I
> 
> Interesting.  The hifi equipment I've dealt with typically doesn't
> present any units at all in the UI outside of level monitors.

My old Yamaha hifi rack had a volume dial where the max was labeled 0
dB and the min setting was -inf dB. My new Yamaha shows the dB level
on an LCD screen whever you touch the volume dial, and it too goes
from -inf dB to 0 dB. I kinda assumed that stereos from other
manufacturers would do the exact same thing, but tbh never checked.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Wed, 17.02.10 10:04, Jaroslav Kysela (perex@perex.cz) wrote:

> The second question is if the represented dB range and scale reported from 
> the driver (hardware and audio chip datasheets) really matches the 
> hardware and how we can measure these values. I suspect a lot of trouble 
> here, because the analog parts of soundcards might have strange curves - 
> it's probably thing you deal with in PA now.

Yes, that is indeed the problem.

For PA I don't care whether the dB curve reported by ALSA might be
shifted relative to some reference level, what matters is that
otherwise the curve reflects properly how volume increases with higher
discrete volume settings.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Wed, Feb 17, 2010 at 11:55:17AM +0000, James Courtier-Dutton wrote:
> On 16 February 2010 23:56, Lennart Poettering <mznyfn@0pointer.de> wrote:
> >
> > The reason I was asking how Jaroslav chose the 0dB position for his
> > measurements was purely because I wanted to do my own measurements for
> > that Aureon card. The dbmeasure tool I wrote for stuff like that puts
> > 0dB at max amplification, however Jaroslav didn't, so I was wondering
> > how he chose 0dB then.
> >
> > Lennart
> >
> 
> I think the digital side is clear. So I will not go into that.
> 
> I think we need to separate the analogue side into a number of categories:
> 1) Standard consumer line-out levels.
> 2) Standard pro line-out levels.
> 3) Consumer line-in levels.
> 4) Pro line-in levels.
> 5) Consumer mic levels.
> 6) Pro mic levels.
> 7) Consumer speaker levels.
> 8) Pro speaker levels.

There's also headphones there, though for both speakers and headphones
it's questionable if we want to do anything.

> On the analogue side, I believe the 0dB gain point is intended to be
> the point at which one can be fairly sure that the distortion will be
> low for a sensible full scale input.

Generally 0dB is pass through (which does also tend to be the optimal
performance point).  Actual expected gain levels will vary depending on
application - for example, a microphone input will usually need an
amplifier with fairly high gain in the path to get the signal to a level
usable by the rest of the system.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mads Kiilerich]

On 02/17/2010 02:01 PM, Lennart Poettering wrote:
> On Wed, 17.02.10 11:17, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
>
>> On Wed, Feb 17, 2010 at 12:56:58AM +0100, Lennart Poettering wrote:
>>
>>> Nah. I actually don't need this value for PulseAudio. In PulseAudio I
>>> chose to shift all scales so that maximum amplification becomes 0 dB,
>>> so that the UIs are similar to how most hifi racks do it, and which I
>>
>> Interesting.  The hifi equipment I've dealt with typically doesn't
>> present any units at all in the UI outside of level monitors.
>
> My old Yamaha hifi rack had a volume dial where the max was labeled 0
> dB and the min setting was -inf dB. My new Yamaha shows the dB level
> on an LCD screen whever you touch the volume dial, and it too goes
> from -inf dB to 0 dB. I kinda assumed that stereos from other
> manufacturers would do the exact same thing, but tbh never checked.

At least some of them do it differently:
http://en.wikipedia.org/wiki/Up_to_eleven

/Mads

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Wed, 17.02.10 12:06, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:

> I'd actually be surprised if there were too much of an issue with this
> beyond the data collection one (especially for USB devices).

I wonder if we could harvest this in some way from the Windows
drivers? Does Windows care about the dB data at all? Maybe one could
extract this information from their .inf files or so, if they store it
there?

At least the Vista APIs seem to expose dB data:

http://msdn.microsoft.com/en-us/library/dd371447%28VS.85%29.aspx

I wonder where they get that data from and what they do with broken
hardware like the Aureon... Now I wished I had access to a Windows
machine to figure that out...

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Wed, Feb 17, 2010 at 02:15:48PM +0100, Lennart Poettering wrote:

> I wonder if we could harvest this in some way from the Windows
> drivers? Does Windows care about the dB data at all? Maybe one could
> extract this information from their .inf files or so, if they store it
> there?

It could well be, for this sort of stuff grovelling around in the MSDN
driver kit documentation will normally turn something up.

> I wonder where they get that data from and what they do with broken
> hardware like the Aureon... Now I wished I had access to a Windows
> machine to figure that out...

IME this is dealt with by the manufacturer providing a driver, a device
specific driver will bind in preference to a class driver and with
Windows it's much more normal to ship a device specific driver along
with the device.  I've no knowledge of Windows audio drivers, though.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[James Courtier-Dutton]

On 17 February 2010 13:06, Lennart Poettering <mznyfn@0pointer.de> wrote:
> On Wed, 17.02.10 10:04, Jaroslav Kysela (perex@perex.cz) wrote:
>
>> The second question is if the represented dB range and scale reported from
>> the driver (hardware and audio chip datasheets) really matches the
>> hardware and how we can measure these values. I suspect a lot of trouble
>> here, because the analog parts of soundcards might have strange curves -
>> it's probably thing you deal with in PA now.
>
> Yes, that is indeed the problem.
>
> For PA I don't care whether the dB curve reported by ALSA might be
> shifted relative to some reference level, what matters is that
> otherwise the curve reflects properly how volume increases with higher
> discrete volume settings.
>

So what you want it this.
Example 1:
If there are 2 gain controls between the CPU and the line-out.
A is at 0dB
B is at 0dB

If one changes A to +3dB and B to -3dB and one was playing a quiet
sound (so no distortion), the result should sound very similar, volume
wise, to the original 0dB, 0dB state.

Example 2:
There is one gain control between the CPU and the line-out that we are
interested in.
A is at 0dB.

If one changes A to +3dB and at the same time modify the source signal
digitally by -3dB, the result should sound very similar, volume wise,
to the original.

You would have to build your test tool so that it would detect
distortion as well as levels.This way you could also find out where
the limits really are in the chain.

This is a good aim, but I still think getting the correct 0dB points
is more important to ensure the best audio quality.
I personally think that PA should just set the hardware ALSA controls
to 0dB and do all the volume control in software within PA.
The 0dB points in hardware should result in the best sound quality.

James

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Wed, Feb 17, 2010 at 01:55:08PM +0000, James Courtier-Dutton wrote:

> I personally think that PA should just set the hardware ALSA controls
> to 0dB and do all the volume control in software within PA.
> The 0dB points in hardware should result in the best sound quality.

That's not universally true - for example, with microphones you really
do want to have substantial amplification before the ADC sees them,
otherwise you'll at best get poor resolution due to the signal being
nowhere near full scale.  Sometimes this will be done by a fixed gain
stage that isn't visible to software, but not always.  Things in the
digital domain also tend to be at least equivalent to doing the work in
the CPU.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Wed, 17.02.10 13:55, James Courtier-Dutton (james.dutton@gmail.com) wrote:

> So what you want it this.
> Example 1:
> If there are 2 gain controls between the CPU and the line-out.
> A is at 0dB
> B is at 0dB
> 
> If one changes A to +3dB and B to -3dB and one was playing a quiet
> sound (so no distortion), the result should sound very similar, volume
> wise, to the original 0dB, 0dB state.

Exactly.

> Example 2:
> There is one gain control between the CPU and the line-out that we are
> interested in.
> A is at 0dB.
> 
> If one changes A to +3dB and at the same time modify the source signal
> digitally by -3dB, the result should sound very similar, volume wise,
> to the original.

Exactly. And this second case is what dbverify from my little tool set
verifies.

> You would have to build your test tool so that it would detect
> distortion as well as levels.This way you could also find out where
> the limits really are in the chain.

I am not sure I want to get lost in complexities like that. My
simplified world where all elements in the pipeline are perfect,
linear multiplicators is oh so cozy, that I am happy to keep my eyes
shut and ignore that the actual filters implemented in the various
elements might be vastly more complex.

In fact dbmeasure and dbverify pick a 440Hz tone for their tests, so
all the volume factors I measure and rely on focus on one point in the
frequency spectrum and leave it at that.

Of course, this is a drastic simplification, but it should be
good enough on most cards and for desktop audio.

> This is a good aim, but I still think getting the correct 0dB points
> is more important to ensure the best audio quality.
> I personally think that PA should just set the hardware ALSA controls
> to 0dB and do all the volume control in software within PA.
> The 0dB points in hardware should result in the best sound quality.

I don't think this would be a good idea. In a lot of hardware you
definitely want to make as much use of the built-in volume adjustment
capabilities as you can. For example, on my integrated USB speakers
you may control the built-in amplifier with the alsa mixer, and that's
definitely much better than attenuating the 16bit PCM stream and
having the USB speakers amplifier constantly configured to a very high
volume level.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Wed, 17.02.10 11:30, Raymond Yau (superquad.vortex2@gmail.com) wrote:

> 
> 2010/2/16 Lennart Poettering <mznyfn@0pointer.de>
> 
> > On Tue, 16.02.10 09:08, Clemens Ladisch (clemens@ladisch.de) wrote:
> >
> > >
> > > Lennart Poettering wrote:
> > > > Getting back to the invalid dB data from the USB cards: the question
> > > > is whether the USB descriptor data is badly parsed, and the dB
> > > > mismatch hence systematic for USB cards,
> > >
> > > USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB.
> > > When the level is computed from the minimum plus a multiple of the step
> > > size, rounding errors add up considerately.
> > >
> > > ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the
> > > range with the min/max values to minimize those rounding errors.
> >
> > I am really sure that the discrepancy I measure with the Aureon is way
> > beyond rounding errors.
> >
> > Lennart
> >
> >
> if the program use a format FLOAT_LE  which is not supported by the hardware
> and need to use plughw , you have already added error ( resampling and
> format conversion ) to the result

That numeric noise is neglible in contrast to the big (20dB or so?)
discrepancy I am seeing here.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[James Courtier-Dutton]

On 17 February 2010 14:35, Lennart Poettering <mznyfn@0pointer.de> wrote:
>
>> This is a good aim, but I still think getting the correct 0dB points
>> is more important to ensure the best audio quality.
>> I personally think that PA should just set the hardware ALSA controls
>> to 0dB and do all the volume control in software within PA.
>> The 0dB points in hardware should result in the best sound quality.
>
> I don't think this would be a good idea. In a lot of hardware you
> definitely want to make as much use of the built-in volume adjustment
> capabilities as you can. For example, on my integrated USB speakers
> you may control the built-in amplifier with the alsa mixer, and that's
> definitely much better than attenuating the 16bit PCM stream and
> having the USB speakers amplifier constantly configured to a very high
> volume level.
>

I was thinking more specifically of the line-out and line-in where
knowing the 0dB gain points is very useful and what most people need,
with maybe a new dBv or dBu

Mic and Speaker amp levels is a whole other kettle of fish.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 Lennart Poettering <mznyfn@0pointer.de>

> On Tue, 16.02.10 23:38, Mark Brown (broonie@opensource.wolfsonmicro.com)
> wrote:
>
> >
> > On Tue, Feb 16, 2010 at 11:42:12PM +0100, Lennart Poettering wrote:
> > > On Tue, 16.02.10 22:39, Mark Brown (
> broonie@opensource.wolfsonmicro.com) wrote:
> >
> > > > Typically the DACs and ADCs will have a full scale signal at line
> > > > reference level - it should generally be a good approximation with
> > > > nothing else to go on.
> >
> > > "line reference level"? What is that?
> >
> > As I understand it (and bear in mind that I'm a software rather than
> > electrical engineer) it's not 100% fixed, though since the actual result
> > depends very much on what it's connected to an absolute answer isn't as
> > important as it might be.  1V RMS is very standard in consumer stuff at
> > least.
> >
> > If you could frame exactly the information that you're looking for then
> > I should be able to ask a few people who are electrical engineers and
> > get a more coherent answer for you.   I guess you're looking at trying
> > to have PulseAudio set sensible levels by default?
>
> Nah. I actually don't need this value for PulseAudio. In PulseAudio I
> chose to shift all scales so that maximum amplification becomes 0 dB,
> so that the UIs are similar to how most hifi racks do it, and which I
> think is a nice, easy and understandable logic. That way my volume
> scales range from -inf dB to 0 dB in all cases, regardless of the
> hardware/drivers in use. Of course, that means that ALSA's own 0dB is
> not directly visible on the scale. Because it might be sometimes
> useful to know where it is, we export that position as "base volume"
> and the UIs show it with a little marker at the side.
>
> The reason I was asking how Jaroslav chose the 0dB position for his
> measurements was purely because I wanted to do my own measurements for
> that Aureon card. The dbmeasure tool I wrote for stuff like that puts
> 0dB at max amplification, however Jaroslav didn't, so I was wondering
> how he chose 0dB then.
>
> Lennart
>
> From the viewpoint of user, they only care how easy to find the point which
is no software gain or software auttentation  since software gain lead to
clipping

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 Eliot Blennerhassett <linux@audioscience.com>

> 2) Absolute calibration of output levels.
> (This is *not* required to solve Lennart's problem)
> This would be required if you wanted two different (brands of) soundcard
> to output the same voltage for given source pcm.
>
>
On windows ,there are benchmark program to compare the sound card 's SNR at
different rate , format

http://audio.rightmark.org/

can the program be used to measure SNR ?

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Thu, 18.02.10 09:48, Raymond Yau (superquad.vortex2@gmail.com) wrote:

> From the viewpoint of user, they only care how easy to find the point which
> is no software gain or software auttentation  since software gain lead to
> clipping

We decided to expose software amplification in the UI, since it is
actually a much requested feature, and I have used myself a couple of
times.

The primary use case is when you play a DVD (which very often has
audio normalized to a very low volume) on weak speakers, such as
laptop speakers.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/18 Lennart Poettering <mznyfn@0pointer.de>

> On Thu, 18.02.10 09:48, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> > From the viewpoint of user, they only care how easy to find the point
> which
> > is no software gain or software auttentation  since software gain lead to
> > clipping
>
> We decided to expose software amplification in the UI, since it is
> actually a much requested feature, and I have used myself a couple of
> times.
>
> The primary use case is when you play a DVD (which very often has
> audio normalized to a very low volume) on weak speakers, such as
> laptop speakers.
>
> Lennart
>
>
VLC media player has a slider from 0% to 300% , so the user are easily to
know  100% is the point which there is no software gain and no software
autentation

How did PA expose these software amplication in the UI so that ordinary user
can know that point ?

For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat
Volume" model if you did not expost the Mic Boost switch to the user in the
mixer control ?

+20dB is quite significant in with the Capture Volume control

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[James Courtier-Dutton]

On 18 February 2010 06:15, Raymond Yau <superquad.vortex2@gmail.com> wrote:
>>
>>
> VLC media player has a slider from 0% to 300% , so the user are easily to
> know  100% is the point which there is no software gain and no software
> autentation
>

I would have thought that VLC should have used dB for the gain.
In that case 100% == 0dB.
What would 50% be?  -6dB ?
As sound volumes are not linear, they are exponential, the dB
logarithmic scale is the best one to use.

The 0dB point is fairly easy for a user to understand.
I find it easier to understand that %

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Thu, 18.02.10 14:15, Raymond Yau (superquad.vortex2@gmail.com) wrote:

> VLC media player has a slider from 0% to 300% , so the user are easily to
> know  100% is the point which there is no software gain and no software
> autentation
> 
> How did PA expose these software amplication in the UI so that ordinary user
> can know that point ?

Depends on the UI program. gnome-volume-control currently only puts a
marker at the ALSA 0dB point, but not a second one where software amp
starts.

However, I have been talking to a couple of folks regarding presenting
that in a nicer way, i.e. colour slider ranges green/yellow/red:

http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders

Summary: green → all hw vol control where alsa reports < 0dB; yellow →
hw control where alsa reports > 0dB; and finally red → software volume
control.

I think this color coding of the slider ranges is the best once can do
to represent the technical background of all of this in a way that
gives the right indication even for people with no technical background.

> For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat
> Volume" model if you did not expost the Mic Boost switch to the user in the
> mixer control ?
> 
> +20dB is quite significant in with the Capture Volume control

We currently don't cover boost switches, simply because tehre is no dB
data queriable for them.

I'd really prefer if those boost switches would be turned into binary
volume elements which carry normal dB information like any other
volume element. After all they are just a volume element, with only
two steps.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Thu, 18 Feb 2010, Lennart Poettering wrote:

>> For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat
>> Volume" model if you did not expost the Mic Boost switch to the user in the
>> mixer control ?
>> 
>> +20dB is quite significant in with the Capture Volume control
>
> We currently don't cover boost switches, simply because tehre is no dB
> data queriable for them.
>
> I'd really prefer if those boost switches would be turned into binary
> volume elements which carry normal dB information like any other
> volume element. After all they are just a volume element, with only
> two steps.

I like this idea.

 				Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Mark Brown]

On Fri, Feb 19, 2010 at 09:17:01AM +0100, Jaroslav Kysela wrote:
> On Thu, 18 Feb 2010, Lennart Poettering wrote:

> > I'd really prefer if those boost switches would be turned into binary
> > volume elements which carry normal dB information like any other
> > volume element. After all they are just a volume element, with only
> > two steps.

> I like this idea.

Me too, in fact I've already been doing it for drivers I've been working
on.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/19 Jaroslav Kysela <perex@perex.cz>

> On Thu, 18 Feb 2010, Lennart Poettering wrote:
>
> >> For the Mic Boost +20dB case , how PA handle this +20dB switch in the
> "Flat
> >> Volume" model if you did not expost the Mic Boost switch to the user in
> the
> >> mixer control ?
> >>
> >> +20dB is quite significant in with the Capture Volume control
> >
> > We currently don't cover boost switches, simply because tehre is no dB
> > data queriable for them.
> >
> > I'd really prefer if those boost switches would be turned into binary
> > volume elements which carry normal dB information like any other
> > volume element. After all they are just a volume element, with only
> > two steps.
>
> I like this idea.
>
>                                Jaroslav
>
>
PA assume every sound card can only record from one capture source at the
same time (like those AC97 card )

However HDA support multi streaming capture , the capture device 0 may have
more than one subdevice "Capture sources"  depend on the codec and  device
2  has 2 subdevice for capturing "Input sources" on some codec

Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct
mixer control for these kind of capturing subdevices  ? ( simple mixer api
is not able to know the subdevice number )

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[James Courtier-Dutton]

On 19 February 2010 08:17, Jaroslav Kysela <perex@perex.cz> wrote:
> On Thu, 18 Feb 2010, Lennart Poettering wrote:
>
>>> For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat
>>> Volume" model if you did not expost the Mic Boost switch to the user in the
>>> mixer control ?
>>>
>>> +20dB is quite significant in with the Capture Volume control
>>
>> We currently don't cover boost switches, simply because tehre is no dB
>> data queriable for them.
>>
>> I'd really prefer if those boost switches would be turned into binary
>> volume elements which carry normal dB information like any other
>> volume element. After all they are just a volume element, with only
>> two steps.
>
> I like this idea.
>

Seems like a good idea but what should we call it.
If we already have a mic capture gain control, what shall we call the
mic boost gain control so as not to confuse it with each other?
Would keeping its current name be OK?

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Fri, 19.02.10 11:47, James Courtier-Dutton (james.dutton@gmail.com) wrote:

> 
> On 19 February 2010 08:17, Jaroslav Kysela <perex@perex.cz> wrote:
> > On Thu, 18 Feb 2010, Lennart Poettering wrote:
> >
> >>> For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat
> >>> Volume" model if you did not expost the Mic Boost switch to the user in the
> >>> mixer control ?
> >>>
> >>> +20dB is quite significant in with the Capture Volume control
> >>
> >> We currently don't cover boost switches, simply because tehre is no dB
> >> data queriable for them.
> >>
> >> I'd really prefer if those boost switches would be turned into binary
> >> volume elements which carry normal dB information like any other
> >> volume element. After all they are just a volume element, with only
> >> two steps.
> >
> > I like this idea.
> >
> 
> Seems like a good idea but what should we call it.
> If we already have a mic capture gain control, what shall we call the
> mic boost gain control so as not to confuse it with each other?
> Would keeping its current name be OK?

Keeping the current names sounds reasonable to me.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Fri, 19.02.10 18:57, Raymond Yau (superquad.vortex2@gmail.com) wrote:

> PA assume every sound card can only record from one capture source at the
> same time (like those AC97 card )

That is true. PA does not try to cover the complete functionality of
the hardware. We limit ourselves to what we think is common on the
desktop or in a mobile environment, and I don't think recording from
mic and line-in at the same time would be useful in more than
exceptional cases.

> Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct
> mixer control for these kind of capturing subdevices  ? ( simple mixer api
> is not able to know the subdevice number )

There is currently no API at all to figure out the relation between PCM
devices and mixer controls in ALSA. PA hences bases this all on
assumptions and expectes in this acse that the first mixer control is
also the first PCM device, if you understand what I mean by that.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 Jaroslav Kysela <perex@perex.cz>

> On Tue, 16 Feb 2010, Lennart Poettering wrote:
>
> > On Tue, 16.02.10 14:40, Mark Brown (broonie@opensource.wolfsonmicro.com)
> wrote:
> >
> >>
> >> On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
> >>> On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
> >>
> >>>> Line: 0dB..47.81dB         # seems correct -47.81dB..0dB
> >>>> Line Capture: -0.18dB..23.81dB     # seems correct
> >>>> -17.81dB..6.18dB
> >>
> >>> Hmm, how did you choose where to put 0dB?
> >>
> >> The Line one looks like someone got attenuation and gain confused, which
> >> is a fairly common mistake for people to make when copying information
> >> from one place to another.  Possibly a similar thing going on with the
> >> Line Capture control, plus a fixed 6dB gain (which may well be a
> >> separate amp...).
> >
> > I remember that a while back we had a discussion on alsa-devel
> > regarding the fact that ALSA does not define relative to what the dB
> > values reported by the mixer elements actually are measured. Some
> > mixer controls export dB values relative to max amplification (e.g. my
> > integrated USB speakers here), others relative to the output of some
> > other mixer element, and others relative to different standard or
> > not-so-standard output voltages.  And there is no API to figure out
> > what the base is.
> >
> > Now, what Jaroslav listed above suggests that he chose carefully where
> > he put 0dB. I was just wondering about that. Jaroslav, how did you
> > choose where to put 0dB?
>
> Basically, if I remember correctly the discussion, 0dB on all elements
> should main unchanged volume, <0dB attenuation and >0dB gain. We cannot
> measure precisely other components on path like analog volume wheels
> (like SB MP3+ has to change line-out volume), analog amplifiers and other
> analog signal modificators.
>
> So, if you use one headphones and speakers with defined and fixed volume
> settings, you can measure differences for the card with broken dB volume
> ranges. I just used another HDA card in notebook with 0dB settings on all
> playback controls on path, captured stream from this card on my USB card
> and played this stream back on my USB card watching and relating the
> volume levels according dB values. It's not 100% correct, but at least
> it's something to start with.
>
>                                        Jaroslav
>
>  <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>
>

Yes, 0dB for 10 bands graphic equalizer of au8830 should be no gain and no
attenuation

how can I calibrate the au8830 10 bands equalizer control as there are 10
bands peak values ?

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Fri, 19 Feb 2010, Raymond Yau wrote:

> 2010/2/19 Jaroslav Kysela <perex@perex.cz>
>
>> On Thu, 18 Feb 2010, Lennart Poettering wrote:
>>
>>>> For the Mic Boost +20dB case , how PA handle this +20dB switch in the
>> "Flat
>>>> Volume" model if you did not expost the Mic Boost switch to the user in
>> the
>>>> mixer control ?
>>>>
>>>> +20dB is quite significant in with the Capture Volume control
>>>
>>> We currently don't cover boost switches, simply because tehre is no dB
>>> data queriable for them.
>>>
>>> I'd really prefer if those boost switches would be turned into binary
>>> volume elements which carry normal dB information like any other
>>> volume element. After all they are just a volume element, with only
>>> two steps.
>>
>> I like this idea.
>>
>>                                Jaroslav
>>
>>
> PA assume every sound card can only record from one capture source at the
> same time (like those AC97 card )
>
> However HDA support multi streaming capture , the capture device 0 may have
> more than one subdevice "Capture sources"  depend on the codec and  device
> 2  has 2 subdevice for capturing "Input sources" on some codec
>
> Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct
> mixer control for these kind of capturing subdevices  ? ( simple mixer api
> is not able to know the subdevice number )

This API is not implemented at the time.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Jaroslav Kysela]

On Fri, 19 Feb 2010, James Courtier-Dutton wrote:

> On 19 February 2010 08:17, Jaroslav Kysela <perex@perex.cz> wrote:
>> On Thu, 18 Feb 2010, Lennart Poettering wrote:
>>
>>>> For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat
>>>> Volume" model if you did not expost the Mic Boost switch to the user in the
>>>> mixer control ?
>>>>
>>>> +20dB is quite significant in with the Capture Volume control
>>>
>>> We currently don't cover boost switches, simply because tehre is no dB
>>> data queriable for them.
>>>
>>> I'd really prefer if those boost switches would be turned into binary
>>> volume elements which carry normal dB information like any other
>>> volume element. After all they are just a volume element, with only
>>> two steps.
>>
>> I like this idea.
>>
>
> Seems like a good idea but what should we call it.
> If we already have a mic capture gain control, what shall we call the
> mic boost gain control so as not to confuse it with each other?
> Would keeping its current name be OK?

I would keep the Boost suffix. It's easy to understand.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/19 Lennart Poettering <mznyfn@0pointer.de>

> On Fri, 19.02.10 18:57, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> > PA assume every sound card can only record from one capture source at the
> > same time (like those AC97 card )
>
> That is true. PA does not try to cover the complete functionality of
> the hardware. We limit ourselves to what we think is common on the
> desktop or in a mobile environment, and I don't think recording from
> mic and line-in at the same time would be useful in more than
> exceptional cases.
>

http://www.intel.com/design/chipsets/hdaudio.htm

The most common onboard audio is HDA so this is not any exceptional cases

Those HDA multi streaming  feature are most users wanted in desktop
enviornment, are pulseaudio really designed for deskop or just only for
notebook and mobile ?

The front panel green/pink jack can be used by one application while the
rear panel audio jacks can be used to another application for surround or
mic for karaoke


*When AC‘97 was initially developed*, users were typically listening to only
music and movies with stereo sound. With the success of DVD movies encoded
with Dolby* Digital and DTS* multi-channel audio formats, users have become
accustomed to listening in full surround sound with anywhere from six to
eight speakers. While AC‘97 technology has struggled to keep pace with all
these advancements, Intel High Definition Audio is designed specifically for
the high-quality multi-channel audio experiences. Newer audio and video
encoding/decoding algorithms also enable a higher-quality listening
experience.



*Consumers also want the ability to play back two different audio tracks*,
such as a CD and a DVD simultaneously, which can't be done using current
audio solutions. Intel HD Audio features multi-streaming capabilities that
give users the ability to send two or more different audio streams to
different locations at the same time, from the same PC.



 Send a game's sound through 5.1 speakers while the Internet chatting audio
is sent through your headset.

 Send a DVD movie with 5.1 audio to a surround sound system in the living
room, while you listen to digital music and surf the Web on the PC.



>
> > Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct
> > mixer control for these kind of capturing subdevices  ? ( simple mixer
> api
> > is not able to know the subdevice number )
>
> There is currently no API at all to figure out the relation between PCM
> devices and mixer controls in ALSA. PA hences bases this all on
> assumptions and expectes in this acse that the first mixer control is
> also the first PCM device, if you understand what I mean by that.
>
> Lennart
>

THe point is that PA release/close the device (suspend on idle) , if another
application using the subdevice 0 before PA resume/reopen, PA will open
subdevice 1 and cannot find the correct capture volume control and user will
complain they cannot record

Since PA did not check the subdevice number to find the correct mixer
control

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/19 Lennart Poettering <mznyfn@0pointer.de>

>
>
> > Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct
> > mixer control for these kind of capturing subdevices  ? ( simple mixer
> api
> > is not able to know the subdevice number )
>
> There is currently no API at all to figure out the relation between PCM
> devices and mixer controls in ALSA. PA hences bases this all on
> assumptions and expectes in this acse that the first mixer control is
> also the first PCM device, if you understand what I mean by that.
>
> Lennart
>
>
No, there is API which allow PA to find out the correct mixer control

However Simple Mixer API cannot know the subdevice number , you have to use
control API ( the lower level API used by Simple Mixer API )

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/22 Lennart Poettering <mznyfn@0pointer.de>

> On Sun, 21.02.10 11:49, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> > The most common onboard audio is HDA so this is not any exceptional cases
> >
> > Those HDA multi streaming  feature are most users wanted in desktop
> > enviornment, are pulseaudio really designed for deskop or just only for
> > notebook and mobile ?
> >
> > The front panel green/pink jack can be used by one application while the
> > rear panel audio jacks can be used to another application for surround or
> > mic for karaoke
>
> I am not entirely convinced that this is really a common case.
>

VT17xx codec already support independent HP mode

http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=cdc1784d49258198df600fbc1d37c07d7eee5ed6

**** List of PLAYBACK Hardware Devices ****

card 0: SB [HDA ATI SB], device 0: VT1708S Analog [VT1708S Analog]
  Subdevices: 1/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
card 0: SB [HDA ATI SB], device 1: VT1708S Digital [VT1708S Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


**** List of CAPTURE Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: VT1708S Analog [VT1708S Analog]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1



AD1988B 10 channels codec  on my ASUS P5BV  already has 3 capture subdevices

**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
  Subdevices: 3/3
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
card 0: Intel [HDA Intel], device 1: AD198x Digital [AD198x Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


http://www.analog.com/en/audiovideo-products/audio-codecs/ad1988b/products/product.html

The AD1988A and AD1988B have 10 DACs and 6 ADCs,
Analog mixer supports recording and playback of signals from multiple
sources

ALC88x

**** List of CAPTURE Hardware Devices ****
card 0: VT82xx [HDA VIA VT82xx], device 0: ALC888 Analog [ALC888 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: VT82xx [HDA VIA VT82xx], device 2: ALC888 Analog [ALC888 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0



Do any PA developer has a desktop computer  with HDA audio ?



> But anyway, there is nothing in PA that would limit it to not use
> multiple parallel devices of a sound card at the same time, with the
> exception that ALSA currently has no enumeration API which could
> inform us which uses of the card are exclusive each other and which
> ones are not. PA currently tries to open the sound card in all
> combinations possible, assuming that EBUSY means it found an invalid
> combination. If one day ALSA gains an API that allows figuring out
> which combinations of streams are possible and which ones are not, I
> am happy to reinvestigate the whole issue.
>
> >  Send a game's sound through 5.1 speakers while the Internet chatting
> audio
> > is sent through your headset.
>
> More often than not you'd probably use two seperate cards for that.
>
> > Send a DVD movie with 5.1 audio to a surround sound system in the living
> > room, while you listen to digital music and surf the Web on the PC.
>
> I somehow doubt that this is the most common of use cases we need to
> care about.
>
> > THe point is that PA release/close the device (suspend on idle) , if
> another
> > application using the subdevice 0 before PA resume/reopen, PA will open
> > subdevice 1 and cannot find the correct capture volume control and user
> will
> > complain they cannot record
> >
> > Since PA did not check the subdevice number to find the correct mixer
> > control
>
> I'd certainly check the subdevice id if the smixer API would supply me
> with it.
>

if ( snd_pcm_info_get_subdevices_count(pcm_info) > 1 ) && (
snd_pcm_info_get_subdevices_count(pcm_info) < 8 ))

snd_mixer_selem_id_set_index(sid, snd_pcm_info_get_subdevice(pcm_info));



>
> Lennart
>
>

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/22 Lennart Poettering <mznyfn@0pointer.de>

> On Sun, 21.02.10 11:49, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> > The most common onboard audio is HDA so this is not any exceptional cases
> >
> > Those HDA multi streaming  feature are most users wanted in desktop
> > enviornment, are pulseaudio really designed for deskop or just only for
> > notebook and mobile ?
> >
> > The front panel green/pink jack can be used by one application while the
> > rear panel audio jacks can be used to another application for surround or
> > mic for karaoke
>
> I am not entirely convinced that this is really a common case.
>
> But anyway, there is nothing in PA that would limit it to not use
> multiple parallel devices of a sound card at the same time, with the
> exception that ALSA currently has no enumeration API which could
> inform us which uses of the card are exclusive each other and which
> ones are not. PA currently tries to open the sound card in all
> combinations possible, assuming that EBUSY means it found an invalid
> combination.


if  ( snd_pcm_info_get_subdevices_count(pcm_info) > 1 ) mean you can open
the device more than one time since the device has more than 1 subdevice

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/22 Lennart Poettering <mznyfn@0pointer.de>

> On Sun, 21.02.10 11:49, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> > The most common onboard audio is HDA so this is not any exceptional cases
> >
> > Those HDA multi streaming  feature are most users wanted in desktop
> > enviornment, are pulseaudio really designed for deskop or just only for
> > notebook and mobile ?
> >
> > The front panel green/pink jack can be used by one application while the
> > rear panel audio jacks can be used to another application for surround or
> > mic for karaoke
>
>
> >  Send a game's sound through 5.1 speakers while the Internet chatting
> audio
> > is sent through your headset.
>
> More often than not you'd probably use two seperate cards for that.
>

why do you need another sound card when you onboard audio HDA already
support this feature ?

e.g. Skype can use alsa hw device for better latency
l<http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>

>

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Clemens Ladisch]

Lennart Poettering wrote:
> On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com) wrote:
> > However Simple Mixer API cannot know the subdevice number , you have to use
> > control API ( the lower level API used by Simple Mixer API )
> 
> Unfortunately there is no way from the simple mixer to the lower level
> mixer.

>From the check_unplugged function in alsa-utils/alsamixer/mixer_widget.c:

	err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl);
	if (err >= 0)
		ctl = snd_hctl_ctl(hctl);

> It would be great if the smixer would include some API that gives me a
> hint to which device/subdevice a specific snd_mixer_elem_t belongs to.

Often, there is no 1:1 correspondence between mixer elements and PCM
devices.  Only mixer controls with interface PCM (not MIXER) have (sub-)
device numbers, and at the moment this is used only for controls that
are associated with the streams of hardware-mixing-capable cards.

Getting information about the mixer layout (like the nodes reported by
HDA and USB devices) is on the TODO list; the only reason it isn't being
implemented is lack of time.


Regards,
Clemens

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/23 Clemens Ladisch <clemens@ladisch.de>

> Lennart Poettering wrote:
> > On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com) wrote:
> > > However Simple Mixer API cannot know the subdevice number , you have to
> use
> > > control API ( the lower level API used by Simple Mixer API )
> >
> > Unfortunately there is no way from the simple mixer to the lower level
> > mixer.
>
> From the check_unplugged function in alsa-utils/alsamixer/mixer_widget.c:
>
>        err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl);
>        if (err >= 0)
>                ctl = snd_hctl_ctl(hctl);
>
> > It would be great if the smixer would include some API that gives me a
> > hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
>
> Often, there is no 1:1 correspondence between mixer elements and PCM
> devices.  Only mixer controls with interface PCM (not MIXER) have (sub-)
> device numbers, and at the moment this is used only for controls that
> are associated with the streams of hardware-mixing-capable cards.
>
> Getting information about the mixer layout (like the nodes reported by
> HDA and USB devices) is on the TODO list; the only reason it isn't being
> implemented is lack of time.
>
>
> Regards,
> Clemens
>
>

for hda , Since PA server open pcm device , so it still can use

snd_mixer_selem_id_set_index(sid, snd_pcm_info_get_subdevice(pcm_info));

pavucontrol still can query PA server to get the sudevice numer
whenever PA resum from suspend

But gnome volume control has no way to know which application open
which subdevice

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Tue, 23.02.10 12:47, Raymond Yau (superquad.vortex2@gmail.com) wrote:

> > > The most common onboard audio is HDA so this is not any exceptional cases
> > >
> > > Those HDA multi streaming  feature are most users wanted in desktop
> > > enviornment, are pulseaudio really designed for deskop or just only for
> > > notebook and mobile ?
> > >
> > > The front panel green/pink jack can be used by one application while the
> > > rear panel audio jacks can be used to another application for surround or
> > > mic for karaoke
> >
> > I am not entirely convinced that this is really a common case.

Uh, I wanted to say "use case" here...

> Do any PA developer has a desktop computer  with HDA audio ?

I certainly do. But the fact that this is not the most common use case
and the ALSA API is not really up to the task yet to query the full
routing table I am not sure supporting parallel and independant
streaming support for heapdphones and speakers should be a priority for PA.

> if ( snd_pcm_info_get_subdevices_count(pcm_info) > 1 ) && (
> snd_pcm_info_get_subdevices_count(pcm_info) < 8 ))
> 
> snd_mixer_selem_id_set_index(sid, snd_pcm_info_get_subdevice(pcm_info));

Are you suggesting that on all drivers the the index part of a
snd_mixer_selem_id_t directly relates to the subdevice id of a PCM
stream on the same card? Is that true? Jaroslav, Clemens, Takashi, can
you say something about that?

(tbh I find that very unlikely, given that the device index would not be
encoded then)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Lennart Poettering]

On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:

> 
> Lennart Poettering wrote:
> > On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com) wrote:
> > > However Simple Mixer API cannot know the subdevice number , you have to use
> > > control API ( the lower level API used by Simple Mixer API )
> > 
> > Unfortunately there is no way from the simple mixer to the lower level
> > mixer.
> 
> >From the check_unplugged function in alsa-utils/alsamixer/mixer_widget.c:
> 
> 	err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl);
> 	if (err >= 0)
> 		ctl = snd_hctl_ctl(hctl);

But that still doesn't give me a hint which snd_ctl_eleme_t belongs to
which snd_mixer_eleme_t, does it?

> > It would be great if the smixer would include some API that gives me a
> > hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
> 
> Often, there is no 1:1 correspondence between mixer elements and PCM
> devices.  Only mixer controls with interface PCM (not MIXER) have (sub-)
> device numbers, and at the moment this is used only for controls that
> are associated with the streams of hardware-mixing-capable cards.

Which are not that many, right? Not HDA at least?

> Getting information about the mixer layout (like the nodes reported by
> HDA and USB devices) is on the TODO list; the only reason it isn't being
> implemented is lack of time.

Would be great to have that.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/24 Lennart Poettering <mznyfn@0pointer.de>

> On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:
>
> >
> > Lennart Poettering wrote:
> > > On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com)
> wrote:
> > > > However Simple Mixer API cannot know the subdevice number , you have
> to use
> > > > control API ( the lower level API used by Simple Mixer API )
> > >
> > > Unfortunately there is no way from the simple mixer to the lower level
> > > mixer.
>
>
> > > It would be great if the smixer would include some API that gives me a
> > > hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
> >
> > Often, there is no 1:1 correspondence between mixer elements and PCM
> > devices.  Only mixer controls with interface PCM (not MIXER) have (sub-)
> > device numbers, and at the moment this is used only for controls that
> > are associated with the streams of hardware-mixing-capable cards.
>
> Which are not that many, right? Not HDA at least?
>


Card hw:1 'Intel'/'HDA Intel at 0xff9f4000 irq 22'
  Mixer name    : 'Analog Devices AD1988'
  Components    : 'HDA:11d41988'
  Controls      : 48
  Simple ctrls  : 26

Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 54
  Front Left: Capture 39 [72%] [0.00dB] [off]
  Front Right: Capture 39 [72%] [0.00dB] [off]
Simple mixer control 'Capture',1
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 54
  Front Left: Capture 39 [72%] [0.00dB] [off]
  Front Right: Capture 39 [72%] [0.00dB] [off]
Simple mixer control 'Capture',2
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 54
  Front Left: Capture 39 [72%] [0.00dB] [off]
  Front Right: Capture 39 [72%] [0.00dB] [off]


Simple mixer control 'Input Source',0
  Capabilities: cenum
  Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix'
  Item0: 'Mic'
Simple mixer control 'Input Source',1
  Capabilities: cenum
  Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix'
  Item0: 'Front Mic'
Simple mixer control 'Input Source',2
  Capabilities: cenum
  Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix'
  Item0: 'Front Mic'

    control.28 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture Switch'
        value.0 false
        value.1 false
    }
    control.29 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 54'
        comment.dbmin -5850
        comment.dbmax 2250
        iface MIXER
        name 'Capture Volume'
        index 1
        value.0 39
        value.1 39
    }
    control.30 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture Switch'
        index 1
        value.0 false
        value.1 false
    }
    control.31 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 54'
        comment.dbmin -5850
        comment.dbmax 2250
        iface MIXER
        name 'Capture Volume'
        index 2
        value.0 39
        value.1 39
    }
    control.32 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture Switch'
        index 2
        value.0 false
        value.1 false
    }
    control.33 {
        comment.access 'read write'
        comment.type ENUMERATED
        comment.count 1
        comment.item.0 'Front Mic'
        comment.item.1 Line
        comment.item.2 Mic
        comment.item.3 CD
        comment.item.4 Mix
        iface MIXER
        name 'Input Source'
        value Mic
    }
    control.34 {
        comment.access 'read write'
        comment.type ENUMERATED
        comment.count 1
        comment.item.0 'Front Mic'
        comment.item.1 Line
        comment.item.2 Mic
        comment.item.3 CD
        comment.item.4 Mix
        iface MIXER
        name 'Input Source'
        index 1
        value 'Front Mic'
    }
    control.35 {
        comment.access 'read write'
        comment.type ENUMERATED
        comment.count 1
        comment.item.0 'Front Mic'
        comment.item.1 Line
        comment.item.2 Mic
        comment.item.3 CD
        comment.item.4 Mix
        iface MIXER
        name 'Input Source'
        index 2
        value 'Front Mic'
    }


>
> > Getting information about the mixer layout (like the nodes reported by
> > HDA and USB devices) is on the TODO list; the only reason it isn't being
> > implemented is lack of time.
>
> Would be great to have that.
>
> Lennart
>
>

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/23 Clemens Ladisch <clemens@ladisch.de>

> Lennart Poettering wrote:
> > On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com) wrote:
> > > However Simple Mixer API cannot know the subdevice number , you have to
> use
> > > control API ( the lower level API used by Simple Mixer API )
> >
> > Unfortunately there is no way from the simple mixer to the lower level
> > mixer.
>
> Often, there is no 1:1 correspondence between mixer elements and PCM
> devices.  Only mixer controls with interface PCM (not MIXER) have (sub-)
> device numbers, and at the moment this is used only for controls that
> are associated with the streams of hardware-mixing-capable cards.
>

But there is really 1:1 correspondence for HDA capture sudevices and the
control related to capturing

card 1: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
  Subdevices: 3/3
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2

Card hw:1 'Intel'/'HDA Intel at 0xff9f4000 irq 22'
  Mixer name    : 'Analog Devices AD1988'
  Components    : 'HDA:11d41988'
  Controls      : 48
  Simple ctrls  : 26

Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 54
  Front Left: Capture 39 [72%] [0.00dB] [off]
  Front Right: Capture 39 [72%] [0.00dB] [off]
Simple mixer control 'Capture',1
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 54
  Front Left: Capture 39 [72%] [0.00dB] [off]
  Front Right: Capture 39 [72%] [0.00dB] [off]
Simple mixer control 'Capture',2
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 54
  Front Left: Capture 39 [72%] [0.00dB] [off]
  Front Right: Capture 39 [72%] [0.00dB] [off]


Simple mixer control 'Input Source',0
  Capabilities: cenum
  Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix'
  Item0: 'Mic'
Simple mixer control 'Input Source',1
  Capabilities: cenum
  Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix'
  Item0: 'Front Mic'
Simple mixer control 'Input Source',2
  Capabilities: cenum
  Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix'
  Item0: 'Front Mic'

    control.28 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture Switch'
        value.0 false
        value.1 false
    }
    control.29 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 54'
        comment.dbmin -5850
        comment.dbmax 2250
        iface MIXER
        name 'Capture Volume'
        index 1
        value.0 39
        value.1 39
    }
    control.30 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture Switch'
        index 1
        value.0 false
        value.1 false
    }
    control.31 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 54'
        comment.dbmin -5850
        comment.dbmax 2250
        iface MIXER
        name 'Capture Volume'
        index 2
        value.0 39
        value.1 39
    }
    control.32 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture Switch'
        index 2
        value.0 false
        value.1 false
    }
    control.33 {
        comment.access 'read write'
        comment.type ENUMERATED
        comment.count 1
        comment.item.0 'Front Mic'
        comment.item.1 Line
        comment.item.2 Mic
        comment.item.3 CD
        comment.item.4 Mix
        iface MIXER
        name 'Input Source'
        value Mic
    }
    control.34 {
        comment.access 'read write'
        comment.type ENUMERATED
        comment.count 1
        comment.item.0 'Front Mic'
        comment.item.1 Line
        comment.item.2 Mic
        comment.item.3 CD
        comment.item.4 Mix
        iface MIXER
        name 'Input Source'
        index 1
        value 'Front Mic'
    }
    control.35 {
        comment.access 'read write'
        comment.type ENUMERATED
        comment.count 1
        comment.item.0 'Front Mic'
        comment.item.1 Line
        comment.item.2 Mic
        comment.item.3 CD
        comment.item.4 Mix
        iface MIXER
        name 'Input Source'
        index 2
        value 'Front Mic'
    }







>
> Getting information about the mixer layout (like the nodes reported by
> HDA and USB devices) is on the TODO list; the only reason it isn't being
> implemented is lack of time.
>
>
> Regards,
> Clemens
>

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/24 Lennart Poettering <mznyfn@0pointer.de>

> On Tue, 23.02.10 12:47, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> > > > The most common onboard audio is HDA so this is not any exceptional
> cases
> > > >
> > > > Those HDA multi streaming  feature are most users wanted in desktop
> > > > enviornment, are pulseaudio really designed for deskop or just only
> for
> > > > notebook and mobile ?
> > > >
> > > > The front panel green/pink jack can be used by one application while
> the
> > > > rear panel audio jacks can be used to another application for
> surround or
> > > > mic for karaoke
> > >
> > > I am not entirely convinced that this is really a common case.
>
> Uh, I wanted to say "use case" here...
>
> > Do any PA developer has a desktop computer  with HDA audio ?
>
> I certainly do. But the fact that this is not the most common use case
> and the ALSA API is not really up to the task yet to query the full
> routing table I am not sure supporting parallel and independant
> streaming support for heapdphones and speakers should be a priority for PA.
>
> > if ( snd_pcm_info_get_subdevices_count(pcm_info) > 1 ) && (
> > snd_pcm_info_get_subdevices_count(pcm_info) < 8 ))
> >
> > snd_mixer_selem_id_set_index(sid, snd_pcm_info_get_subdevice(pcm_info));
>
> Are you suggesting that on all drivers the the index part of a
> snd_mixer_selem_id_t directly relates to the subdevice id of a PCM
> stream on the same card? Is that true? Jaroslav, Clemens, Takashi, can
> you say something about that?
>
> (tbh I find that very unlikely, given that the device index would not be
> encoded then)
>
> Lennart
>

This is only true for those Capture controls for HDA since only HDA support
multi streaming

The reason of using ( snd_pcm_info_get_subdevices_
count(pcm_info) < 8 ) is au88x0 have at least 8 capture subdevices which
capture from one source from AC97 codec

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/23 Clemens Ladisch <clemens@ladisch.de>

> Lennart Poettering wrote:
>
>
>  Only mixer controls with interface PCM (not MIXER) have (sub-)
> device numbers, and at the moment this is used only for controls that
> are associated with the streams of hardware-mixing-capable cards.
>
>
> Regards,
> Clemens
>

Just implementing those IFACE_PCM control for the driver is not enough for
any practical use

Will need an API which allow the application to change the hardware per
stream volume in optimized way by calling one api ? ( e.g. those API is need
for if wine want to implement the real hardware acclerated dsound for those
hardware mixing sound cards which support at least 16 voices )

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/20 Jaroslav Kysela <perex@perex.cz>

> On Fri, 19 Feb 2010, James Courtier-Dutton wrote:
>
> > On 19 February 2010 08:17, Jaroslav Kysela <perex@perex.cz> wrote:
> >> On Thu, 18 Feb 2010, Lennart Poettering wrote:
> >>
> >>>> For the Mic Boost +20dB case , how PA handle this +20dB switch in the
> "Flat
> >>>> Volume" model if you did not expost the Mic Boost switch to the user
> in the
> >>>> mixer control ?
> >>>>
> >>>> +20dB is quite significant in with the Capture Volume control
> >>>
> >>> We currently don't cover boost switches, simply because tehre is no dB
> >>> data queriable for them.
> >>>
> >>> I'd really prefer if those boost switches would be turned into binary
> >>> volume elements which carry normal dB information like any other
> >>> volume element. After all they are just a volume element, with only
> >>> two steps.
> >>
> >> I like this idea.
> >>
> >
> > Seems like a good idea but what should we call it.
> > If we already have a mic capture gain control, what shall we call the
> > mic boost gain control so as not to confuse it with each other?
> > Would keeping its current name be OK?
>
> I would keep the Boost suffix. It's easy to understand.
>
>                                        Jaroslav
>
> -


Some HDA codec has Front Mic Boost and Mic Boost  and three sets of input
sources

it is not easy to know the exact audio path

Card hw:1 'Intel'/'HDA Intel at 0xff9f4000 irq 22'
  Mixer name    : 'Analog Devices AD1988'
  Components    : 'HDA:11d41988'
  Controls      : 48
  Simple ctrls  : 26


    control.25 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 3'
        comment.dbmin 0
        comment.dbmax 3000
        iface MIXER
        name 'Front Mic Boost'
        value.0 0
        value.1 0
    }
    control.26 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 3'
        comment.dbmin 0
        comment.dbmax 3000
        iface MIXER
        name 'Mic Boost'
        value.0 0
        value.1 0
    }

    control.27 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 54'
        comment.dbmin -5850
        comment.dbmax 2250
        iface MIXER
        name 'Capture Volume'
        value.0 39
        value.1 39
    }
    control.28 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture Switch'
        value.0 false
        value.1 false
    }
    control.29 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 54'
        comment.dbmin -5850
        comment.dbmax 2250
        iface MIXER
        name 'Capture Volume'
        index 1
        value.0 39
        value.1 39
    }
    control.30 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture Switch'
        index 1
        value.0 false
        value.1 false
    }
    control.31 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 54'
        comment.dbmin -5850
        comment.dbmax 2250
        iface MIXER
        name 'Capture Volume'
        index 2
        value.0 39
        value.1 39
    }
    control.32 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture Switch'
        index 2
        value.0 false
        value.1 false
    }
    control.33 {
        comment.access 'read write'
        comment.type ENUMERATED
        comment.count 1
        comment.item.0 'Front Mic'
        comment.item.1 Line
        comment.item.2 Mic
        comment.item.3 CD
        comment.item.4 Mix
        iface MIXER
        name 'Input Source'
        value Mic
    }
    control.34 {
        comment.access 'read write'
        comment.type ENUMERATED
        comment.count 1
        comment.item.0 'Front Mic'
        comment.item.1 Line
        comment.item.2 Mic
        comment.item.3 CD
        comment.item.4 Mix
        iface MIXER
        name 'Input Source'
        index 1
        value 'Front Mic'
    }
    control.35 {
        comment.access 'read write'
        comment.type ENUMERATED
        comment.count 1
        comment.item.0 'Front Mic'
        comment.item.1 Line
        comment.item.2 Mic
        comment.item.3 CD
        comment.item.4 Mix
        iface MIXER
        name 'Input Source'
        index 2
        value 'Front Mic'
    }

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Clemens Ladisch]

Lennart Poettering wrote:
> On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:
> > Lennart Poettering wrote:
> > > Unfortunately there is no way from the simple mixer to the lower level
> > > mixer.
> > 
> > From the check_unplugged function in alsa-utils/alsamixer/mixer_widget.c:
> > 
> > 	err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl);
> > 	if (err >= 0)
> > 		ctl = snd_hctl_ctl(hctl);
> 
> But that still doesn't give me a hint which snd_ctl_eleme_t belongs to
> which snd_mixer_eleme_t, does it?

Not really; the point of the simple mixer interface is to abstract away
some of the ctl naming conventions.

> > > It would be great if the smixer would include some API that gives me a
> > > hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
> > 
> > Often, there is no 1:1 correspondence between mixer elements and PCM
> > devices.  Only mixer controls with interface PCM (not MIXER) have (sub-)
> > device numbers, and at the moment this is used only for controls that
> > are associated with the streams of hardware-mixing-capable cards.
> 
> Which are not that many, right? Not HDA at least?

No, most recent hardware was designed for software mixing.  Only the
snd-emu10k1, snd-via82xx and snd-ymfpci drivers implement such controls.


Regards,
Clemens

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/24 Clemens Ladisch <clemens@ladisch.de>

> Lennart Poettering wrote:
> > On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:
> > > Lennart Poettering wrote:
> > > > Unfortunately there is no way from the simple mixer to the lower
> level
> > > > mixer.
> > >
> > > From the check_unplugged function in
> alsa-utils/alsamixer/mixer_widget.c:
> > >
> > >     err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl);
> > >     if (err >= 0)
> > >             ctl = snd_hctl_ctl(hctl);
> >
> > But that still doesn't give me a hint which snd_ctl_eleme_t belongs to
> > which snd_mixer_eleme_t, does it?
>
> Not really; the point of the simple mixer interface is to abstract away
> some of the ctl naming conventions.
>
> > > > It would be great if the smixer would include some API that gives me
> a
> > > > hint to which device/subdevice a specific snd_mixer_elem_t belongs
> to.
> > >
> > > Often, there is no 1:1 correspondence between mixer elements and PCM
> > > devices.  Only mixer controls with interface PCM (not MIXER) have
> (sub-)
> > > device numbers, and at the moment this is used only for controls that
> > > are associated with the streams of hardware-mixing-capable cards.
> >
> > Which are not that many, right? Not HDA at least?
>
> No, most recent hardware was designed for software mixing.  Only the
> snd-emu10k1, snd-via82xx and snd-ymfpci drivers implement such controls.
>
>
> Regards,
> Clemens
>
>
The current implementation of HDA capturing subdevices are almost as same as
those playback subdevices of hardware mixing sound card

each subdevice support the same format , rate , channels , the number of
input sources are also the same

The only difference is the type IFACE_MIXER and IFACE_PCM since using
IFACE_PCM will break most mixer application

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/24 Clemens Ladisch <clemens@ladisch.de>

> Lennart Poettering wrote:
> > On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:
> > > Lennart Poettering wrote:
> > > > Unfortunately there is no way from the simple mixer to the lower
> level
> > > > mixer.
> > >
> > > From the check_unplugged function in
> alsa-utils/alsamixer/mixer_widget.c:
> > >
> > >     err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl);
> > >     if (err >= 0)
> > >             ctl = snd_hctl_ctl(hctl);
> >
> > But that still doesn't give me a hint which snd_ctl_eleme_t belongs to
> > which snd_mixer_eleme_t, does it?
>
> Not really; the point of the simple mixer interface is to abstract away
> some of the ctl naming conventions.
>
> > > > It would be great if the smixer would include some API that gives me
> a
> > > > hint to which device/subdevice a specific snd_mixer_elem_t belongs
> to.
> > >
> > > Often, there is no 1:1 correspondence between mixer elements and PCM
> > > devices.  Only mixer controls with interface PCM (not MIXER) have
> (sub-)
> > > device numbers, and at the moment this is used only for controls that
> > > are associated with the streams of hardware-mixing-capable cards.
> >
> > Which are not that many, right? Not HDA at least?
>
> No, most recent hardware was designed for software mixing.  Only the
> snd-emu10k1, snd-via82xx and snd-ymfpci drivers implement such controls.
>
>
> Regards,
> Clemens
>
>
However the playback subdevices of some HDA codec did not support the same
range of channels

(e.g. vt1708s has two playback subdevices ,

 if independent HP mode is ON , one subdevice can only suppport 2 channels
and the other subdevices support 2 ,4 ,6

if independent HP mode is OFF , the subdevice may support 2, 4, 6 and 8
channels

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/20 Jaroslav Kysela <perex@perex.cz>

> On Fri, 19 Feb 2010, Raymond Yau wrote:
>
>
>>>
>>>  PA assume every sound card can only record from one capture source at
>> the
>> same time (like those AC97 card )
>>
>> However HDA support multi streaming capture , the capture device 0 may
>> have
>> more than one subdevice "Capture sources"  depend on the codec and  device
>> 2  has 2 subdevice for capturing "Input sources" on some codec
>>
>> Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct
>> mixer control for these kind of capturing subdevices  ? ( simple mixer api
>> is not able to know the subdevice number )
>>
>
> This API is not implemented at the time.
>
>                                        Jaroslav
>


How did the current implementation of VIA Smart 5.1 and Independent HP mode
affect alsa application such as pulseaudio ?

There are two playback subdevices and driver is supposed to support 5.1
smartly when the speaker jack is plugged


But PA developer seem expect an "2 4 6 channels switch" in all HDA codec

**** List of PLAYBACK Hardware Devices ****

card 0: NVidia [HDA NVidia], device 0: VT1708S Analog [VT1708S Analog]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1

http://pulseaudio.org/ticket/743

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4895

seem bug in alsa driver for rear channels ?

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/18 Lennart Poettering <mznyfn@0pointer.de>

> On Thu, 18.02.10 09:48, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> > From the viewpoint of user, they only care how easy to find the point
> which
> > is no software gain or software auttentation  since software gain lead to
> > clipping
>
> We decided to expose software amplification in the UI, since it is
> actually a much requested feature, and I have used myself a couple of
> times.
>
> The primary use case is when you play a DVD (which very often has
> audio normalized to a very low volume) on weak speakers, such as
> laptop speakers.
>
> Lennart
>
> --
>
There are many mixer switch need to export to the mixer control

some are hardware specific and some are AC 97 standard feature which affect
the dB volume

e.g. ac97 standard external amplifier

    control.52 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 1
        iface MIXER
        name 'External Amplifier'
        value true
    }
}

and codec specifc

Sigmatel Surround Playback Volume which change the ratio of  volume of
"front" and "rear" channels

so the overall dB in the front speaker is also affected by this volume
control


    control.20 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 31'
        comment.dbmin -4650
        comment.dbmax 0
        iface MIXER
        name 'Sigmatel Surround Playback Volume'
        value.0 0
        value.1 0

    control.50 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 1
        iface MIXER
        name 'Sigmatel 4-Speaker Stereo Playback Switch'
        value false
    }

    control.49 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 1
        iface MIXER
        name 'Sigmatel Output Bias Switch'
        value false
    }

    control.51 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 1
        iface MIXER
        name 'Sigmatel Surround Phase Inversion Playback '
        value true
    }

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/19 Lennart Poettering <mznyfn@0pointer.de>

> On Thu, 18.02.10 14:15, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> > VLC media player has a slider from 0% to 300% , so the user are easily to
> > know  100% is the point which there is no software gain and no software
> > autentation
> >
> > How did PA expose these software amplication in the UI so that ordinary
> user
> > can know that point ?
>
> Depends on the UI program. gnome-volume-control currently only puts a
> marker at the ALSA 0dB point, but not a second one where software amp
> starts.
>

For example , your program dbmeasure.c generate a full amplitude sine wave ,
the sine wave will be clipped for any software gain by pulseaudio , any
hardware att. by DAC cannot change the clipped sine wave

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 Lennart Poettering <mznyfn@0pointer.de>

>
>
>
>
> Hmm, so you basically tuned the USB card's DAC/ADC level to the HDA
> card's DAC/ADC.
>
> I now measured the "Master" slider of my aureon (USB 0ccd:0028,
> TerraTec Aureon 5.1 MkII) with the aforementioned dbmeasure tool and a
> loopback cable. The aureon has 65536 volume steps, but
> I was too lazy to measure them all. So I only measured every
> 3000th. From the max volume to the min volume:
>
> 65536 0 dB
> 62536 0.00560039 dB
> 59536 0.00694678 dB
> 56536 0.00616732 dB
> 53536 0.00645077 dB
> 50536 0.00673421 dB
> 47536 -1.49514 dB
> 44536 -1.49455 dB
> 41536 -1.49648 dB
> 38536 -2.98666 dB
> 35536 -2.98486 dB
> 32536 -2.98536 dB
> 29536 -4.48688 dB
> 26536 -6.00084 dB
> 23536 -5.99928 dB
> 20536 -9.00246 dB
> 17536 -10.5425 dB
> 14536 -16.5274 dB
> 11536 -32.9435 dB
> 8536 -43.4326 dB
> 5536 -43.5066 dB
> 2536 -43.2968 dB
> 0 -43.4431 dB
>
> If you plot this it looks as if the card actually only implements 10
> or so discrete steps, and at around 10000 just becomes a constant
> function.
>
> ALSA reports -47.87 .. -1.97 for this. So it seems the overall range
> the USB data reports is not really that far off, but the volume
> function in bteween is.
>
> The noise level of these measurements is < -58 dB.
>
> What's the next step with this measurement data? Will you take it from
> here, or shall I provide you with more data?
>
> Lennart
>

How about dbmeasure the pulse device since the volume control seem also have
65536 step ?

Can you provide the result for the pulse device ?

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 Lennart Poettering <mznyfn@0pointer.de>

>
>
> Nah. I actually don't need this value for PulseAudio. In PulseAudio I
> chose to shift all scales so that maximum amplification becomes 0 dB,
> so that the UIs are similar to how most hifi racks do it, and which I
> think is a nice, easy and understandable logic. That way my volume
> scales range from -inf dB to 0 dB in all cases, regardless of the
> hardware/drivers in use. Of course, that means that ALSA's own 0dB is
> not directly visible on the scale. Because it might be sometimes
> useful to know where it is, we export that position as "base volume"
> and the UIs show it with a little marker at the side.
>

For AC97 Record gain registers 1ch

-inf dB to 22.5 dB

The default value is 0x8000 which is correspond to 0dB gain when mute on

Not sure your way of shifting all scales so that maximum amplification
becomes 0 dB has any effect on the calculation since there is 22.5dB gain
when you recording by all AC97 codec



> The reason I was asking how Jaroslav chose the 0dB position for his
> measurements was purely because I wanted to do my own measurements for
> that Aureon card. The dbmeasure tool I wrote for stuff like that puts
> 0dB at max amplification, however Jaroslav didn't, so I was wondering
> how he chose 0dB then.
>
> Lennart
>
> --
>
>

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/16 Lennart Poettering <mznyfn@0pointer.de>

>
>
> Invalid dB data from the driver is a real problem for the "flat
> volume" logic in PA. We basically allow each app to control the full
> hw volume range individually, and then set the hw volume to the max of
> what all apps wanted and attenuate the other streams accordingly. On
> the Aureon this doesn't work at all, since the attenuation of the
> streams is miscalculated due to the invalid dB data.
>
> Lennart
>
>
>
Refer to http://pulseaudio.org/wiki/BadDecibel

If (when flat volumes are enabled in PulseAudio) the playback volume of one
stream changes whenever another stream is played, this is most likely caused
be incorrect dB attenuation data exposed by the ALSA kernel driver.

This seem to the software attenuation of the playback volume when PA
software mix two or more playback streams

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 James Courtier-Dutton <james.dutton@gmail.com>

>
> This is a good aim, but I still think getting the correct 0dB points
> is more important to ensure the best audio quality.
> I personally think that PA should just set the hardware ALSA controls
> to 0dB and do all the volume control in software within PA.
> The 0dB points in hardware should result in the best sound quality.
>
> James
>
>
When you mix two stream of 16-bit audio and send to a 16 bit sound card ,
you have to add two 16-bit and shift right one bit ,

you have already add -3dB by software when perform soft mixing and you may
need to get +3dB gain in DAC if you want to maintain the same dB level if
one stream is actually silence

so set the hardware ALSA controls to 0dB is not that good for a sound server

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/16 Lennart Poettering <mznyfn@0pointer.de>

> Heya,
>
>
> Invalid dB data from the driver is a real problem for the "flat
> volume" logic in PA. We basically allow each app to control the full
> hw volume range individually, and then set the hw volume to the max of
> what all apps wanted and attenuate the other streams accordingly. On
> the Aureon this doesn't work at all, since the attenuation of the
> streams is miscalculated due to the invalid dB data.
>
> Lennart
>

The real problem for the "flat volume" logic in PA is when you set the
hardware device volume to maximum, you cannot compensate the software attent
when PA software mixing two or more audio stream by increase the gain in
DAC

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/24 Lennart Poettering <mznyfn@0pointer.de>

> On Tue, 23.02.10 12:47, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
>
> Are you suggesting that on all drivers the the index part of a
> snd_mixer_selem_id_t directly relates to the subdevice id of a PCM
> stream on the same card? Is that true? Jaroslav, Clemens, Takashi, can
> you say something about that?
>
> (tbh I find that very unlikely, given that the device index would not be
> encoded then)
>
> Lennart
>
>
Those are the per voice volume control of the hardware mixing sound card

This is a little bit different from the pulse pre-application volume control
.

It seem that pulseaudio allow the application open only one audio stream ,
but this per voice volume control allow application to open more than one
audio stream

e.g. Skype need to play the human voice and the ringing bell and it have to
open two audio streams using either two hw devices or dmix

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/16 Lennart Poettering <mznyfn@0pointer.de>

> Heya,
>
>
> Invalid dB data from the driver is a real problem for the "flat
> volume" logic in PA. We basically allow each app to control the full
> hw volume range individually, and then set the hw volume to the max of
> what all apps wanted and attenuate the other streams accordingly. On
> the Aureon this doesn't work at all, since the attenuation of the
> streams is miscalculated due to the invalid dB data.
>
> Lennart
>
>
But PA also did not provide dB information to alsa application through
alsa-pulse plugin

amixer -D pulse
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 65536 [100%] [on]
  Front Right: Playback 65536 [100%] [on]
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch cswitch-joined
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 65536
  Front Left: Capture 65536 [100%] [on]
  Front Right: Capture 65536 [100%] [on]

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 Lennart Poettering <mznyfn@0pointer.de>

> On Tue, 16.02.10 23:38, Mark Brown (broonie@opensource.wolfsonmicro.com)
> wrote:
>
> >
> > On Tue, Feb 16, 2010 at 11:42:12PM +0100, Lennart Poettering wrote:
> > > On Tue, 16.02.10 22:39, Mark Brown (
> broonie@opensource.wolfsonmicro.com) wrote:
> >
> > > > Typically the DACs and ADCs will have a full scale signal at line
> > > > reference level - it should generally be a good approximation with
> > > > nothing else to go on.
> >
> > > "line reference level"? What is that?
> >
> > As I understand it (and bear in mind that I'm a software rather than
> > electrical engineer) it's not 100% fixed, though since the actual result
> > depends very much on what it's connected to an absolute answer isn't as
> > important as it might be.  1V RMS is very standard in consumer stuff at
> > least.
> >
> > If you could frame exactly the information that you're looking for then
> > I should be able to ask a few people who are electrical engineers and
> > get a more coherent answer for you.   I guess you're looking at trying
> > to have PulseAudio set sensible levels by default?
>
> Nah. I actually don't need this value for PulseAudio. In PulseAudio I
> chose to shift all scales so that maximum amplification becomes 0 dB,
> so that the UIs are similar to how most hifi racks do it, and which I
> think is a nice, easy and understandable logic. That way my volume
> scales range from -inf dB to 0 dB in all cases, regardless of the
> hardware/drivers in use. Of course, that means that ALSA's own 0dB is
> not directly visible on the scale. Because it might be sometimes
> useful to know where it is, we export that position as "base volume"
> and the UIs show it with a little marker at the side.
>

The -inf dB is the level determined by the state of the mute switch.

The actual resolution of the codec depend on the number of step and the
resolution of each step


But PA also did not provide dB information to alsa application through
alsa-pulse plugin

amixer -D pulse
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 65536 [100%] [on]
  Front Right: Playback 65536 [100%] [on]

Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch cswitch-joined

  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 65536
  Front Left: Capture 65536 [100%] [on]
  Front Right: Capture 65536 [100%] [on]

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 Lennart Poettering <mznyfn@0pointer.de>

> On Wed, 17.02.10 11:30, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> >
> > 2010/2/16 Lennart Poettering <mznyfn@0pointer.de>
> >
> > > On Tue, 16.02.10 09:08, Clemens Ladisch (clemens@ladisch.de) wrote:
> > >
>
> > >
> > >
> > if the program use a format FLOAT_LE  which is not supported by the
> hardware
> > and need to use plughw , you have already added error ( resampling and
> > format conversion ) to the result
>
> That numeric noise is neglible in contrast to the big (20dB or so?)
> discrepancy I am seeing here.
>
> Lennart
>


For HDA , some codec can playback/record in 16 , 20, 24 or 32 bits , if you
are using non-native format ,

I think there should be some practical difference when HDA codec use 16 ,
24, or 32 bits for running your test

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 James Courtier-Dutton <james.dutton@gmail.com>

> On 16 February 2010 23:56, Lennart Poettering <mznyfn@0pointer.de> wrote:
> >
> > The reason I was asking how Jaroslav chose the 0dB position for his
> > measurements was purely because I wanted to do my own measurements for
> > that Aureon card. The dbmeasure tool I wrote for stuff like that puts
> > 0dB at max amplification, however Jaroslav didn't, so I was wondering
> > how he chose 0dB then.
> >
> > Lennart
> >
>
> I think the digital side is clear. So I will not go into that.
>

The problem is at the digital side , The range between -inf dB and -48dB /
-96dB software atten is lost during the conversion of the floating format
format to S16_LE or S32_LE ( native format supported by hardware driver )

i.e. the bottom part of the pulseaudio volume control cannot be used

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/17 Jaroslav Kysela <perex@perex.cz>

> On Tue, 16 Feb 2010, Lennart Poettering wrote:
>
> > On Tue, 16.02.10 14:40, Mark Brown (broonie@opensource.wolfsonmicro.com)
> wrote:
> >
> >>
> >> On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
> >>> On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
> >>
> >>>> Line: 0dB..47.81dB         # seems correct -47.81dB..0dB
> >>>> Line Capture: -0.18dB..23.81dB     # seems correct
> >>>> -17.81dB..6.18dB
> >>
> >>> Hmm, how did you choose where to put 0dB?
> >>
> >> The Line one looks like someone got attenuation and gain confused, which
> >> is a fairly common mistake for people to make when copying information
> >> from one place to another.  Possibly a similar thing going on with the
> >> Line Capture control, plus a fixed 6dB gain (which may well be a
> >> separate amp...).
> >
> > I remember that a while back we had a discussion on alsa-devel
> > regarding the fact that ALSA does not define relative to what the dB
> > values reported by the mixer elements actually are measured. Some
> > mixer controls export dB values relative to max amplification (e.g. my
> > integrated USB speakers here), others relative to the output of some
> > other mixer element, and others relative to different standard or
> > not-so-standard output voltages.  And there is no API to figure out
> > what the base is.
> >
> > Now, what Jaroslav listed above suggests that he chose carefully where
> > he put 0dB. I was just wondering about that. Jaroslav, how did you
> > choose where to put 0dB?
>
> Basically, if I remember correctly the discussion, 0dB on all elements
> should main unchanged volume, <0dB attenuation and >0dB gain. We cannot
> measure precisely other components on path like analog volume wheels
> (like SB MP3+ has to change line-out volume), analog amplifiers and other
> analog signal modificators.
>
> So, if you use one headphones and speakers with defined and fixed volume
> settings, you can measure differences for the card with broken dB volume
> ranges. I just used another HDA card in notebook with 0dB settings on all
> playback controls on path, captured stream from this card on my USB card
> and played this stream back on my USB card watching and relating the
> volume levels according dB values. It's not 100% correct, but at least
> it's something to start with.
>
>                                        Jaroslav
>  <Alsa-devel@alsa-project.org>
>

Refer  to  http://thread.gmane.org/gmane.linux.alsa.devel/15859

Try to lower "Wave" volume - otherways there will be clipping on bass.

When you set "PCM" to 75 % this is 0 db.

The dB scale of alsa  driver was implemented because of 0dB is not at the
maximum for emu10k1

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/16 Mark Brown <broonie@opensource.wolfsonmicro.com>

> On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
> > On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
>
> > > Line: 0dB..47.81dB          # seems correct -47.81dB..0dB
> > > Line Capture: -0.18dB..23.81dB      # seems correct
> > > -17.81dB..6.18dB
>
> > Hmm, how did you choose where to put 0dB?
>
> The Line one looks like someone got attenuation and gain confused, which
> is a fairly common mistake for people to make when copying information
> from one place to another.  Possibly a similar thing going on with the
> Line Capture control, plus a fixed 6dB gain (which may well be a
> separate amp...).
>

Correct me if I am wrong

0dB point is needed when you recording from line-in by connected loopback
cable to line out.

The captured signal is supposed to be the same as the playback signal when
you set both playback volume and capture volume to 0dB ,

if you set playback volume over 0dB , clipping occur in the captured signal
,

if the playback volume is less than 0dB , captured signal will be less than
the playback signal.

Re: Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII

[Raymond Yau]

2010/2/16 Lennart Poettering <mznyfn@0pointer.de>

> Heya,
>
> a while back I wrote a little tool "dbmeasure" which can be used to
> determine dB attenuation data for alsa mixer controls. I have now
> extended this little dB tools suite to include a tiny tool "dbverify"
> that can be used to verify the correctness of existing dB data exposed
> by the drivers. It should be relatively easy to use that tool,
> suitable even for non-guru folks who want to debug the dB information
> from alsa.
>
> http://git.0pointer.de/?p=dbmeasure.git
> git://git.0pointer.de/dbmeasure.git
>
> Just run "make" in a git checkout and then try:
>
>   $ ./dbverify Aureon51MkII Master 30 200
>
> That will verify the dB data of the "Master" control of the sound card
> that goes by the id "Aureon51MkII". It will compare the discrete
> volume steps 30 and 200: first it will play a full amplitude sine wave
> at mixer volume step 30, and then will change to mixer volume step
> 200, but attenuate the sine wave in software compensating for the
> volume change. So once you hear the sine wave attenuated by the hw,
> and once by the software. If the card's dB data is correct both sines
> should have the same volume.
>
>
> Lennart
>
>
Finally have time and an analog loop back cable to test your program
dbverify.c

It really depend on your ear to do the verifcation which is not really
scientific

Unfortunately , I am unable to run dbmeasure on both of my au8830 and HDA
sound card

Can you provide any test result of your HDA sound card ?

!) The program dbmeasure.c seem underrun easily since you start the device
and waiting for the user to press enter key

2) it expect the sound driver can provide exactly 1 second buffer because
your logic is generate one second sample,  Neither au8830 nor HDA driver can
provide exactly one second buffer