Alsamixertest

Alsamixertest

[David Henningsson]

Here's the tool "one of the Mandriva guys" ;-) was talking about the 
other day. I should probably have announced it on both lists simultaneously.

Anyway, over the previous weeks I've been working on a small script 
which tests whether the ALSA mixer lives up to PA's expectations. If you 
are familiar with dbmeasure or dbverify by Lennart Poettering, this 
application's purpose is very similar, but this one is hopefully easier 
to set up, more user friendly, and also tests that the names of the 
volume controls are correct.
My hope is that this will aid as a debugging tool for all these 
"everything below 20% of my speaker is muted, and then 21% blows my 
speakers" bugs.

To use the tool, you'll need some kind of loopback. You can e g use a 
loopback cable and connect that between line in and line out, or test 
your laptop's internal speakers with your laptop's internal mic (just 
stop humming when you do so :-) ). Just set up the recording levels 
appropriately.

Alsamixertest is available for Ubuntu Lucid and Ubuntu Maverick from 
these PPAs:
Lucid: https://launchpad.net/~diwic/+archive/ppa
Maverick: https://launchpad.net/~diwic/+archive/maverick

For other distributions, download the tarball:
https://launchpad.net/~diwic/+archive/ppa/+files/alsamixertest_47.14.tar.gz
Unpack and read the readme file for compilation and install instructions.

When it is installed, run "alsamixertest -r" for a small tutorial and 
"alsamixertest -h" for command line options help.

Looking forward to your comments about this new little tool! I think it 
should be considered "beta" quality at this point.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Alsamixertest

[Raymond Yau]

2010/9/29 David Henningsson <david.henningsson@canonical.com>

> Here's the tool "one of the Mandriva guys" ;-) was talking about the
> other day. I should probably have announced it on both lists
> simultaneously.
>
> Anyway, over the previous weeks I've been working on a small script
> which tests whether the ALSA mixer lives up to PA's expectations. If you
> are familiar with dbmeasure or dbverify by Lennart Poettering, this
> application's purpose is very similar, but this one is hopefully easier
> to set up, more user friendly, and also tests that the names of the
> volume controls are correct.
> My hope is that this will aid as a debugging tool for all these
> "everything below 20% of my speaker is muted, and then 21% blows my
> speakers" bugs.
>
> To use the tool, you'll need some kind of loopback. You can e g use a
> loopback cable and connect that between line in and line out, or test
> your laptop's internal speakers with your laptop's internal mic (just
> stop humming when you do so :-) ). Just set up the recording levels
> appropriately.
>
> Alsamixertest is available for Ubuntu Lucid and Ubuntu Maverick from
> these PPAs:
> Lucid: https://launchpad.net/~diwic/+archive/ppa<https://launchpad.net/%7Ediwic/+archive/ppa>
> Maverick: https://launchpad.net/~diwic/+archive/maverick<https://launchpad.net/%7Ediwic/+archive/maverick>
>
> For other distributions, download the tarball:
> https://launchpad.net/~diwic/+archive/ppa/+files/alsamixertest_47.14.tar.gz<https://launchpad.net/%7Ediwic/+archive/ppa/+files/alsamixertest_47.14.tar.gz>
> Unpack and read the readme file for compilation and install instructions.
>
> When it is installed, run "alsamixertest -r" for a small tutorial and
> "alsamixertest -h" for command line options help.
>
> Looking forward to your comments about this new little tool! I think it
> should be considered "beta" quality at this point.
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic <http://launchpad.net/%7Ediwic>
>

Do you need to write your own mixercontrol (amixer parser)  when there is
alsa-python mixercontrol ?

Re: Alsamixertest

[David Henningsson]

On 2010-09-29 11:48, Raymond Yau wrote:
> 2010/9/29 David Henningsson<david.henningsson@canonical.com>
>
>> Here's the tool "one of the Mandriva guys" ;-) was talking about the
>> other day. I should probably have announced it on both lists
>> simultaneously.
>>
>> Anyway, over the previous weeks I've been working on a small script
>> which tests whether the ALSA mixer lives up to PA's expectations. If you
>> are familiar with dbmeasure or dbverify by Lennart Poettering, this
>> application's purpose is very similar, but this one is hopefully easier
>> to set up, more user friendly, and also tests that the names of the
>> volume controls are correct.
>> My hope is that this will aid as a debugging tool for all these
>> "everything below 20% of my speaker is muted, and then 21% blows my
>> speakers" bugs.
>>
>> To use the tool, you'll need some kind of loopback. You can e g use a
>> loopback cable and connect that between line in and line out, or test
>> your laptop's internal speakers with your laptop's internal mic (just
>> stop humming when you do so :-) ). Just set up the recording levels
>> appropriately.
>>
>> Alsamixertest is available for Ubuntu Lucid and Ubuntu Maverick from
>> these PPAs:
>> Lucid: https://launchpad.net/~diwic/+archive/ppa<https://launchpad.net/%7Ediwic/+archive/ppa>
>> Maverick: https://launchpad.net/~diwic/+archive/maverick<https://launchpad.net/%7Ediwic/+archive/maverick>
>>
>> For other distributions, download the tarball:
>> https://launchpad.net/~diwic/+archive/ppa/+files/alsamixertest_47.14.tar.gz<https://launchpad.net/%7Ediwic/+archive/ppa/+files/alsamixertest_47.14.tar.gz>
>> Unpack and read the readme file for compilation and install instructions.
>>
>> When it is installed, run "alsamixertest -r" for a small tutorial and
>> "alsamixertest -h" for command line options help.
>>
>> Looking forward to your comments about this new little tool! I think it
>> should be considered "beta" quality at this point.
>>
>> --
>> David Henningsson, Canonical Ltd.
>> http://launchpad.net/~diwic<http://launchpad.net/%7Ediwic>
>>
>
> Do you need to write your own mixercontrol (amixer parser)  when there is
> alsa-python mixercontrol ?

I wasn't aware of "alsa-python mixercontrol". Thanks for the tip, I will 
consider it the next time I write something in python that needs to 
access the alsa mixer controls.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

how to mandate the use of PCM plugin?

[Stas Sergeev]

  Hi guys.

Is it possible to somehow mandate the
use of a PCM plugin? For example, the
PC-Speaker.conf defines the use of softvol
plugin for "default" and "front" devices.
It is still possible for the software to bypass
it by the use of "hw", and some software
does exactly that.
Is it possible to somehow make some
plugin a mandatory?

Re: how to mandate the use of PCM plugin?

[Mark Brown]

On Sun, Sep 26, 2010 at 07:17:29PM +0400, Stas Sergeev wrote:

> Is it possible to somehow mandate the
> use of a PCM plugin? For example, the
> PC-Speaker.conf defines the use of softvol
> plugin for "default" and "front" devices.
> It is still possible for the software to bypass
> it by the use of "hw", and some software
> does exactly that.
> Is it possible to somehow make some
> plugin a mandatory?

What is the actual problem you are trying to solve here?  It's not
possible to *mandate* anything to all users, if nothing else someone
with administrative access can always rebuild whatever part of the
system is trying to restrict them.

Re: how to mandate the use of PCM plugin?

[Stas Sergeev]

  Hello.

27.09.2010 04:58, Mark Brown wrote:
>> Is it possible to somehow mandate the
>> use of a PCM plugin? For example, the
>> PC-Speaker.conf defines the use of softvol
>> plugin for "default" and "front" devices.
>> It is still possible for the software to bypass
>> it by the use of "hw", and some software
>> does exactly that.
>> Is it possible to somehow make some
>> plugin a mandatory?
> What is the actual problem you are trying to solve here?  It's not
> possible to *mandate* anything to all users, if nothing else someone
> with administrative access can always rebuild whatever part of the
> system is trying to restrict them.
What I am trying to solve, is the problem
that people have with my snd-pcsp driver.
Pulseaudio uses "hw" to bypass some pcm
plugins, and then people are left with the
non-functional softvol control, and they blame
my driver.
I am looking for the way to mandate the
softvol plugin even for the "hw" device.
Is this possible?

Re: how to mandate the use of PCM plugin?

[Colin Guthrie]

'Twas brillig, and Stas Sergeev at 27/09/10 05:48 did gyre and gimble:
>   Hello.
> 
> 27.09.2010 04:58, Mark Brown wrote:
>>> Is it possible to somehow mandate the
>>> use of a PCM plugin? For example, the
>>> PC-Speaker.conf defines the use of softvol
>>> plugin for "default" and "front" devices.
>>> It is still possible for the software to bypass
>>> it by the use of "hw", and some software
>>> does exactly that.
>>> Is it possible to somehow make some
>>> plugin a mandatory?
>> What is the actual problem you are trying to solve here?  It's not
>> possible to *mandate* anything to all users, if nothing else someone
>> with administrative access can always rebuild whatever part of the
>> system is trying to restrict them.
> What I am trying to solve, is the problem
> that people have with my snd-pcsp driver.
> Pulseaudio uses "hw" to bypass some pcm
> plugins, and then people are left with the
> non-functional softvol control, and they blame
> my driver.

FWIW, PA does not actually use "hw" to open the device in most cases. It
actually uses front, surround51 etc. etc.

The volume control pipeline can be summed up here if you're not already
familiar with it:
http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes

which explains how the various mixer elements are used.

It is quite common however for incorrect dB data to be presented from
drivers.

This can be rectified by calculating proper dB information and fixing up
the driver. Some details can be found here:
http://www.pulseaudio.org/wiki/BadDecibel

And today, one of the Canonical guys published his version of a tool to
help here:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/7542

Hope this helps.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: how to mandate the use of PCM plugin?

[Raymond Yau]

2010/9/28 Colin Guthrie <gmane@colin.guthr.ie>

>
>
> And today, one of the Canonical guys published his version of a tool to
> help here:
> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/7542
>
> Hope this helps.
>
> Col
>
>
>
why did runtest.sh use a format  FLOAT64_LE which was not supported by PA ?

 ./runtest.sh pulse pulse
arecord: set_params:1055: Sample format non available
Available formats:
- U8
- S16_LE
- S16_BE
- S32_LE
- S32_BE
- FLOAT_LE
- FLOAT_BE
- MU_LAW
- A_LAW
Could not open file /tmp/dbtest.raw

Re: how to mandate the use of PCM plugin?

[David Henningsson]

On 2010-09-28 06:07, Raymond Yau wrote:
> 2010/9/28 Colin Guthrie<gmane@colin.guthr.ie>
>
>>
>>
>> And today, one of the Canonical guys published his version of a tool to
>> help here:
>> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/7542
>>
>> Hope this helps.
>>
>> Col
>>
>>
>>
> why did runtest.sh use a format  FLOAT64_LE which was not supported by PA ?

runtest.sh isn't meant to be used directly in that way, you're supposed 
to run "alsamixertest". Try "alsamixertest -r" and "alsamixertest -h" to 
get started. (Perhaps I should rename the .sh file to something else.)

That said, if you find a good use case where you want to use it directly 
and need a different sample format - patches welcome (as long as they 
don't break something else).

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: how to mandate the use of PCM plugin?

[Raymond Yau]

2010/9/29 David Henningsson <david.henningsson@canonical.com>

> On 2010-09-28 06:07, Raymond Yau wrote:
> > 2010/9/28 Colin Guthrie<gmane@colin.guthr.ie>
> >
> >>
> >>
> >> And today, one of the Canonical guys published his version of a tool to
> >> help here:
> >> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/7542
> >>
> >> Hope this helps.
> >>
> >> Col
> >>
> >>
> >>
> > why did runtest.sh use a format  FLOAT64_LE which was not supported by PA
> ?
>
> runtest.sh isn't meant to be used directly in that way, you're supposed
> to run "alsamixertest". Try "alsamixertest -r" and "alsamixertest -h" to
> get started. (Perhaps I should rename the .sh file to something else.)
>
> That said, if you find a good use case where you want to use it directly
> and need a different sample format - patches welcome (as long as they
> don't break something else).
>
>
I just try to see whether this tool can help me to calibrate the 10 band
gain/atten controls of the hardware equalizer of au8830.

Have anyone test your tool on the sound card with ac97 codec ?

It seem that the program keep complain about those controls without dB scale
(e.g. AC97 3D Control - depth and rear depth , .) with the emulated intel8x0
driver  and no volume control with the emulated sb16 in virtualbox

Your program seem really behave as same as pulseaudio server , set the dB
value of control but don't verify the dB value can be set by re-reading the
value since dB -> volume conversion

Even though your program start at 0dB  , ac97 volume controls are in 1.5dB
per step but your program use 2 dB step

Still finding why the program running into infinite loop and try to set dB
to -7xx dB , however amixer does output the min dB when 0%

Alsamixertest (was: how to mandate the use of PCM plugin?)

[David Henningsson]

On 2010-10-02 04:11, Raymond Yau wrote:
> 2010/9/29 David Henningsson<david.henningsson@canonical.com>
>
>> On 2010-09-28 06:07, Raymond Yau wrote:
>>> 2010/9/28 Colin Guthrie<gmane@colin.guthr.ie>
>>>
>>>>
>>>>
>>>> And today, one of the Canonical guys published his version of a tool to
>>>> help here:
>>>> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/7542
>>>>
>>>> Hope this helps.
>>>>
>>>> Col
>>>>
>>>>
>>>>
>>> why did runtest.sh use a format  FLOAT64_LE which was not supported by PA
>> ?
>>
>> runtest.sh isn't meant to be used directly in that way, you're supposed
>> to run "alsamixertest". Try "alsamixertest -r" and "alsamixertest -h" to
>> get started. (Perhaps I should rename the .sh file to something else.)
>>
>> That said, if you find a good use case where you want to use it directly
>> and need a different sample format - patches welcome (as long as they
>> don't break something else).
>>
>>
> I just try to see whether this tool can help me to calibrate the 10 band
> gain/atten controls of the hardware equalizer of au8830.

Hmm...there is currently no way to specify control name(s) manually, 
perhaps I should add such a test/switch.

> Have anyone test your tool on the sound card with ac97 codec ?

I don't think so, no.

> It seem that the program keep complain about those controls without dB scale
> (e.g. AC97 3D Control - depth and rear depth , .) with the emulated intel8x0
> driver  and no volume control with the emulated sb16 in virtualbox

It's a righteous warning if you ask me - all volume controls should 
provide dB information, or we don't know what they actually do. It 
doesn't disturb the rest of the test as long as you have set the value 
manually to something that does not destroy the audio.

> Your program seem really behave as same as pulseaudio server , set the dB
> value of control but don't verify the dB value can be set by re-reading the
> value since dB ->  volume conversion

Yes, I do verify: I read back the set value because it is not always the 
same as the actual value I tried to set.

> Even though your program start at 0dB  , ac97 volume controls are in 1.5dB
> per step but your program use 2 dB step

I just released a new version where you can set the step size at the 
command line:

https://edge.launchpad.net/~diwic/+archive/maverick/+files/alsamixertest_48.11.tar.gz

If 1.5 dB is pretty standard in both HDA and AC'97, I should probably 
change it to 1.5 dB by default.

> Still finding why the program running into infinite loop and try to set dB
> to -7xx dB , however amixer does output the min dB when 0%

If you're still having an infinite loop in the 48.11 version, could you 
please send the output of the tool with the -v (verbose) switch to me 
privately? Thanks!

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Alsamixertest

[Clemens Ladisch]

David Henningsson wrote:
> On 2010-10-02 04:11, Raymond Yau wrote:
> > It seem that the program keep complain about those controls without dB scale
> > (e.g. AC97 3D Control - depth and rear depth , .) with the emulated intel8x0
> > driver  and no volume control with the emulated sb16 in virtualbox
> 
> It's a righteous warning if you ask me - all volume controls should
> provide dB information,

But "3D Depth" and some other controls are not volume controls and are
not measured in dB.

> or we don't know what they actually do.

Where "we" = "generic software like PA".  Non-standard controls can be
controlled only by hardware-specific tools or by the user.


Regards,
Clemens

Re: Alsamixertest

[David Henningsson]

On 2010-10-04 14:01, Clemens Ladisch wrote:
> David Henningsson wrote:
>> On 2010-10-02 04:11, Raymond Yau wrote:
>>> It seem that the program keep complain about those controls without dB scale
>>> (e.g. AC97 3D Control - depth and rear depth , .) with the emulated intel8x0
>>> driver  and no volume control with the emulated sb16 in virtualbox
>>
>> It's a righteous warning if you ask me - all volume controls should
>> provide dB information,
>
> But "3D Depth" and some other controls are not volume controls and are
> not measured in dB.
>
>> or we don't know what they actually do.
>
> Where "we" = "generic software like PA".  Non-standard controls can be
> controlled only by hardware-specific tools or by the user.

Exactly, this is a test tool that checks whether the mixer control names 
and dB information live up to PulseAudio's expectations. That's the 
tool's purpose.

Given some thought, perhaps the application warning should be removed. 
It might be that it should only require dB information for the controls 
it actually wants to test (i e Master, PCM etc)...what do you think?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Alsamixertest

[Clemens Ladisch]

David Henningsson wrote:
> On 2010-10-04 14:01, Clemens Ladisch wrote:
> > Non-standard controls can be controlled only by hardware-specific
> > tools or by the user.
> 
> Exactly, this is a test tool that checks whether the mixer control names
> and dB information live up to PulseAudio's expectations. That's the
> tool's purpose.
> 
> Given some thought, perhaps the application warning should be removed.
> It might be that it should only require dB information for the controls
> it actually wants to test (i e Master, PCM etc)...what do you think?

Yes, any program should completely ignore any controls that it doesn't
know or care about.


Regards,
Clemens

Re: Alsamixertest

[Raymond Yau]

2010/10/4 David Henningsson <david.henningsson@canonical.com>

> On 2010-10-02 04:11, Raymond Yau wrote:
> > 2010/9/29 David Henningsson<david.henningsson@canonical.com>
> >
> >> On 2010-09-28 06:07, Raymond Yau wrote:
> >>> 2010/9/28 Colin Guthrie<gmane@colin.guthr.ie>
> >>>
> >>>>
> >>>>
> >>>> And today, one of the Canonical guys published his version of a tool
> to
> >>>> help here:
> >>>> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/7542
> >>>>
> >>>> Hope this helps.
> >>>>
> >>>> Col
> >>>>
> >>>>
> >>>>
> >>> why did runtest.sh use a format  FLOAT64_LE which was not supported by
> PA
> >> ?
> >>
> >> runtest.sh isn't meant to be used directly in that way, you're supposed
> >> to run "alsamixertest". Try "alsamixertest -r" and "alsamixertest -h" to
> >> get started. (Perhaps I should rename the .sh file to something else.)
> >>
> >> That said, if you find a good use case where you want to use it directly
> >> and need a different sample format - patches welcome (as long as they
> >> don't break something else).
>

if it can be used to test the dB scale of the hardware, it can also be used
to verify the dB reported by Gnome Sound Preference and Kmix



> >>
> >>
> > I just try to see whether this tool can help me to calibrate the 10 band
> > gain/atten controls of the hardware equalizer of au8830.
>
> Hmm...there is currently no way to specify control name(s) manually,
> perhaps I should add such a test/switch.
>

Do I need to use same sine wave file or sine wave of different frequency for
the different bands (31Hz, 63Hz, 125Hz, 250Hz, 500Hz, 1KHz, 2KHz, 4 KHz,
8KHz and 16KHz) when testing the 10 bands gain/atten controls of the graphic
equalizer

Do I need to use "speaker-test -t sine -f " instead of  "aplay sine.wav" for
generating sine wave of different frequency?

Any special requirement (e.g. amplitude, frequency, duration of the
recording) of the signal for powerfft to calculate the data on a 32bit
machine?

There is an un-calibrated "EQ peak" control which can obtain the peak value
of 10 bands from au8830 chip at any time.



>
> > Have anyone test your tool on the sound card with ac97 codec ?
>
> I don't think so, no.
>

Why the program only test the volume below 0 dB ?

The dB range of "PCM" volume control of ac97 is  -34.5dB to +12dB



>
> > It seem that the program keep complain about those controls without dB
> scale
> > (e.g. AC97 3D Control - depth and rear depth , .) with the emulated
> intel8x0
> > driver  and no volume control with the emulated sb16 in virtualbox
>
> It's a righteous warning if you ask me - all volume controls should
> provide dB information, or we don't know what they actually do. It
> doesn't disturb the rest of the test as long as you have set the value
> manually to something that does not destroy the audio.
>

Those are 3D effect defined in AC97 codec specification ,  I guess they have
some effect on your calculation if they are not disabled

if you are using the same card for playback/recording , you have to mute
those "Mic", "Video", "CD", "Aux" , "Phone" and "Line" playback volume
controls for a clean playback.
Especially "Line" Playback Volume if the test is done by connecting "Line
Out" to "Line In" with an loopback cable.

Some codec may has specific feature which affect the volume of the output

(e.g. STAC9708 has a "Sigmatel Surround" control which act as "Front/Rear"
balance and the name of this control is "Front/Rear Fader" in windows)
When this "Sigmatel Surround" playback switch is unmuted, you can still hear
sound even if you mute the "PCM" Playback switch


>
> > Your program seem really behave as same as pulseaudio server , set the dB
> > value of control but don't verify the dB value can be set by re-reading
> the
> > value since dB ->  volume conversion
>
> Yes, I do verify: I read back the set value because it is not always the
> same as the actual value I tried to set.
>
> > Even though your program start at 0dB  , ac97 volume controls are in
> 1.5dB
> > per step but your program use 2 dB step
>
> I just released a new version where you can set the step size at the
> command line:
>
>
> https://edge.launchpad.net/~diwic/+archive/maverick/+files/alsamixertest_48.11.tar.gz<https://edge.launchpad.net/%7Ediwic/+archive/maverick/+files/alsamixertest_48.11.tar.gz>
>
>

 Are you sure that the approach of your program is correct ?



 If 1.5 dB is pretty standard in both HDA and AC'97, I should probably
> change it to 1.5 dB by default.
>


No, there are four type of dB info

a) SNDRV_CTL_TLVT_DB_SCALE
b) SNDRV_CTL_TLVT_DB_LINEAR
c) SNDRV_CTL_TLVT_DB_MINMAX

http://thread.gmane.org/gmane.linux.alsa.devel/64055

d) SNDRV_CTL_TLVT_DB_RANGE

http://thread.gmane.org/gmane.linux.alsa.devel/73114


those controls of hda-intel codec and ac97 codec have fixed dB per step
because they belong to TLV_DB_SCALE, but there are sound cards with controls
belong TLV_DB_LINEAR which does not have fixed dB per step (e.g. emu10k1,
....)


1) curr_dB -= stepdB

amixer -D hw:0 -- sset 'Master' -2.0dB
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 29 [94%] [-3.00dB] [on]
  Front Right: Playback 29 [94%] [-3.00dB] [on]

amixer -D hw:0 -- sset 'PCM' 2.0dB
Simple mixer control 'PCM',0
  Capabilities: pvolume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 24 [77%] [1.50dB] [on]
  Front Right: Playback 24 [77%] [1.50dB] [on]

Are you sure that your program 48-11 does read back the dB value -3 or 1.5
for calculation when it try to set dB to -2 or 2 ?


The ALSA volume control allow you to change the volume between the Limits
e.g. The limits of the AC97 Master is  0 - 31 and PCM is 0 - 31
The dB scale is only defined at those 32 points only

The "Master" and "PCM" volume control provide  32+32=64 level of playback
volume

it is just total 64 discrete points if you plotted dB and volume step on a
graph but your program and PA seem expect it is a continuous line

e.g. The number of step of PA 's Master is 65536 ,
how did PA map 65536 steps to 64 steps of AC97 "Master" and "PCM" controls?
PA need to provide software atten (65536-64) out of 65536 times since the
internal format is FLOAT


Should the program test from the max volume to min volume and use
ask_volume_dB() for each step to compare the result of the test ?


2) While True:
        if cond:
            break;

the cause of the infiinte loop is due to the "While True:" loop

if the control has fixed number of step(e.g.   Limits: Playback 0 - 31) ,

why do your program  need to run the test inside a while True loop since the
ALSA control api does not allow your program to set dB outside the allowed
range ?

unless your program can write value to ac97 registers using /proc and
compiled the driver in debug mode

e.g. https://bugs.kde.org/show_bug.cgi?id=249508

when the driver limit the min db to -60 dB , you are unlikely to set dB
value below -60dB
unless you revert the patch

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



> > Still finding why the program running into infinite loop and try to set
> dB
> > to -7xx dB , however amixer does output the min dB when 0%
>
> If you're still having an infinite loop in the 48.11 version, could you
> please send the output of the tool with the -v (verbose) switch to me
> privately? Thanks!
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic <http://launchpad.net/%7Ediwic>
>

Re: Alsamixertest

[Raymond Yau]

2010/10/4 David Henningsson <david.henningsson@canonical.com>

> On 2010-10-04 14:01, Clemens Ladisch wrote:
> > David Henningsson wrote:
> >> On 2010-10-02 04:11, Raymond Yau wrote:
> >>> It seem that the program keep complain about those controls without dB
> scale
> >>> (e.g. AC97 3D Control - depth and rear depth , .) with the emulated
> intel8x0
> >>> driver  and no volume control with the emulated sb16 in virtualbox
> >>
> >> It's a righteous warning if you ask me - all volume controls should
> >> provide dB information,
> >
> > But "3D Depth" and some other controls are not volume controls and are
> > not measured in dB.
> >
> >> or we don't know what they actually do.
> >
> > Where "we" = "generic software like PA".  Non-standard controls can be
> > controlled only by hardware-specific tools or by the user.
>
> Exactly, this is a test tool that checks whether the mixer control names
> and dB information live up to PulseAudio's expectations. That's the
> tool's purpose.
>
> Given some thought, perhaps the application warning should be removed.
> It might be that it should only require dB information for the controls
> it actually wants to test (i e Master, PCM etc)...what do you think?
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic <http://launchpad.net/%7Ediwic>
>

But some drivers (e.g. ISA drivers ) does not provide dB info for "Master"
and "Capture" volume control

There are different model of sound cards using snd-sb16 driver

SB16 support joint duplex , only 16 bit playback and 8 bit capture instead
of 16bits playback and capture

your runtest.sh use "-q" option and I had spend some time to discover the
overrun occur during arecord with sb16 inside virtualbox

Re: Alsamixertest

[Raymond Yau]

2010/10/4 David Henningsson <david.henningsson@canonical.com>
>>I just released a new version where you can set the step size at the
command line:

>>
https://edge.launchpad.net/~diwic/+archive/maverick/+files/alsamixertest_48.11.tar.gz<https://edge.launchpad.net/%7Ediwic/+archive/maverick/+files/alsamixertest_48.11.tar.gz>


Have you performed any test on your HDA-Intel since you have changed
testcase.sh to use "plug:front" as output device ?


softvol plugin of front device of HDA-Intel is 0.2 dB per step (
51dB/255)and what is your HDA master volume 's dB per step ?


StepSize (7 bits) indicates the size of each step in the gain range. Each
individual step may be 0-32 dB specified in 0.25-dB steps. A value of 0
indicates 0.25-dB steps, while a value of 127d indicates a 32-dB step

Re: Alsamixertest

[Raymond Yau]

2010/10/4 David Henningsson <david.henningsson@canonical.com>

>
>
> Exactly, this is a test tool that checks whether the mixer control names
> and dB information live up to PulseAudio's expectations. That's the
> tool's purpose.
>
> What's PulseAudio' s expectation ?

PA 's developer seem expect max_dB of all HDA codec are 0dB

Your alsamixertest program does not test any dB range above 0dB

How does PA handle the mixer control when the dB range of the "Master
Front"  volume control is -34.5dB to +12dB (e.g. vt1708b HDA codec ) is not
live up to PA 's expectation

e.g. No Master Volume Control

http://launchpadlibrarian.net/54333151/Card0.Codecs.codec.0.txt


http://launchpadlibrarian.net/37147347/Card0.Codecs.codec.0.txt

Node 0x16 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In
  Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00
0x00] [0x9f 0x9f] [0x97 0x97]
  Power: setting=D0, actual=D0
  Connection: 7
     0x10 0x1f 0x1a 0x1b 0x1e 0x1d 0x25

Re: Alsamixertest

[David Henningsson]

On 2010-10-21 06:36, Raymond Yau wrote:
> 2010/10/4 David Henningsson<david.henningsson@canonical.com>
>
>>
>>
>> Exactly, this is a test tool that checks whether the mixer control names
>> and dB information live up to PulseAudio's expectations. That's the
>> tool's purpose.
>>
>> What's PulseAudio' s expectation ?
>
> PA 's developer seem expect max_dB of all HDA codec are 0dB
>
> Your alsamixertest program does not test any dB range above 0dB

That's correct, I don't really know how to deal with that, and I'm not 
sure how PA deals with that either. I assume it goes above 0 dB on one 
of the volume controls when a user wants it to.

But from alsamixertest's perspective, the question is: if you do, should 
detected distortion cause an error or not?

Also alsamixertest could be expanded to trust playback and test 
recording, and then I assume this question will be even more important 
as most mic boost controls go from 0 dB to +20 dB or so (if they even 
provide dB information).

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Alsamixertest

[Raymond Yau]

2010/10/21 David Henningsson <david.henningsson@canonical.com>

> On 2010-10-21 06:36, Raymond Yau wrote:
> > 2010/10/4 David Henningsson<david.henningsson@canonical.com>
> >
> >>
> >>
> >> Exactly, this is a test tool that checks whether the mixer control names
> >> and dB information live up to PulseAudio's expectations. That's the
> >> tool's purpose.
> >>
> >> What's PulseAudio' s expectation ?
> >
> > PA 's developer seem expect max_dB of all HDA codec are 0dB
> >
> > Your alsamixertest program does not test any dB range above 0dB
>
> That's correct, I don't really know how to deal with that, and I'm not
> sure how PA deals with that either. I assume it goes above 0 dB on one
> of the volume controls when a user wants it to.
>
>
alsamixertest-48.11 does allow user to specify a negative step to allow test
volume over 0dB , but your program seem go to infinite loop




DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', '--', 'sset',
"'Master',0", '3.000000dB', 'unmute')
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', 'sget', "'Master',0")
DEBUG:root:dB = 3.000000 get 0.000000 gives pstate = {'Front Left':
{'muted': False, 'dB': 0.0, 'value': 31}, 'Front Right': {'muted': False,
'dB': 0.0, 'value': 31}}
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', '--', 'sset',
"'Master',0", '4.500000dB', 'unmute')
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', 'sget', "'Master',0")
DEBUG:root:dB = 4.500000 get 0.000000 gives pstate = {'Front Left':
{'muted': False, 'dB': 0.0, 'value': 31}, 'Front Right': {'muted': False,
'dB': 0.0, 'value': 31}}
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', '--', 'sset',
"'Master',0", '6.000000dB', 'unmute')
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', 'sget', "'Master',0")
DEBUG:root:dB = 6.000000 get 0.000000 gives pstate = {'Front Left':
{'muted': False, 'dB': 0.0, 'value': 31}, 'Front Right': {'muted': False,
'dB': 0.0, 'value': 31}}
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', '--', 'sset',
"'Master',0", '7.500000dB', 'unmute')
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', 'sget', "'Master',0")
DEBUG:root:dB = 7.500000 get 0.000000 gives pstate = {'Front Left':
{'muted': False, 'dB': 0.0, 'value': 31}, 'Front Right': {'muted': False,
'dB': 0.0, 'value': 31}}
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', '--', 'sset',
"'Master',0", '9.000000dB', 'unmute')
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', 'sget', "'Master',0")
DEBUG:root:dB = 9.000000 get 0.000000 gives pstate = {'Front Left':
{'muted': False, 'dB': 0.0, 'value': 31}, 'Front Right': {'muted': False,
'dB': 0.0, 'value': 31}}
DEBUG:root:Run subprocess: ('amixer', '-D', 'hw:0', '--', 'sset',
"'Master',0", '10.500000dB', 'unmute')