how to mandate the use of PCM plugin?

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?

[Mark Brown]

On Mon, Sep 27, 2010 at 08:48:29AM +0400, Stas Sergeev wrote:
> 27.09.2010 04:58, Mark Brown wrote:

> >What is the actual problem you are trying to solve here?  It's not

> 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.

Why not work on fixing the actual problem if it's not already been
fixed?  I'm not clear from your description what that actually is but it
would seem much more generally useful to fix that.  This is far from the
only card with no hardware volume control and I'd imagine all will be
affected.

> Is this possible?

No, and it would still be unhelpful since it would leave you with two
soft volume controls in operation.

Re: how to mandate the use of PCM plugin?

[Stas Sergeev]

  27.09.2010 09:54, Mark Brown wrote:
> >  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.
> Why not work on fixing the actual problem if it's not already been
> fixed?
I am not sure what's the actual fix would
look like. I wasn't followed the alsa development
for a long time. Is there a way to consistently
replace the softvol controls? If so, then there is
a bug somewhere. Also, the snd-pcsp is configured
to use the "asym" plugin - I wonder if it is safe to
replace also that.
So the question is: can _all_ the plugins be safely
replaced by the software that opens "hw", or,
maybe, some are not, and then, they should be
somehow mandated?
>> Is this possible?
> No, and it would still be unhelpful since it would leave you with two
> soft volume controls in operation.
>
But this is not a real problem, this is the same
as if you have the volume control in the hardware.
You then also have 2 volume controls, or more.
And pulseaudio can just check whether or not
the volume control is present, and then simply not
to add its own. I dont think this is a real problem.
The real problem is when the mixer bar doesn't
work at all. :)
So what the real fix do you think of?

Re: how to mandate the use of PCM plugin?

[Stas Sergeev]

  27.09.2010 09:54, Mark Brown wrote:
 > Why not work on fixing the actual problem if it's not already been fixed?
 > I'm not clear from your description what that actually is but it 
would seem
 > much more generally useful to fix that. This is far from the only 
card with
 > no hardware volume control and I'd imagine all will be affected.
I just checked with HDA-Intel, which seems to
have the softvol too, and no, it seems to communicate
fine with the pulseaudio volume. This is not the case
with snd-pcsp though, so indeed, there might just be
some bug. Btw, it is really very easy to test, everyone
has the snd-pcsp to reproduce that. :)
I'll post back when I have more info on what actually
breaks.

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?

[Mark Brown]

On Mon, Sep 27, 2010 at 10:53:49AM +0400, Stas Sergeev wrote:
>  27.09.2010 09:54, Mark Brown wrote:

> >Why not work on fixing the actual problem if it's not already been
> >fixed?

> I am not sure what's the actual fix would
> look like. I wasn't followed the alsa development

I can't really comment since I've no idea what the problem is; if it's
not understood what has gone wrong then some diagnosis will be needed.

> So the question is: can _all_ the plugins be safely
> replaced by the software that opens "hw", or,
> maybe, some are not, and then, they should be
> somehow mandated?

The entire plugin stack is subject to customisation.

> So what the real fix do you think of?

Like I say, I've no idea what the actual problem is so can't really
comment.

Re: how to mandate the use of PCM plugin?

[Raymond Yau]

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

> '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.
>

if snd-pcsp only support mono and the pc speaker is also mono, by removing
"front" device from PC-Speaker.conf will force PA to user "hw"

The point is whether libcanberra ( system event sound) need snd-pcsp to
support stereo

I don't think other media application want to use this beep generator to
play music

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?

[Stas Sergeev]

  28.09.2010 02:00, Mark Brown wrote:
> I can't really comment since I've no idea what the problem is; if it's
> not understood what has gone wrong then some diagnosis will be needed.
For now, all I can say is that the softvol
doesn't communicate with pulseaudio when
snd-pcsp is used. You can alter it, but the
playback volume won't change. And if you
run the pulseaudio mixer in parallel, it won't
reflect the change done by alsamixer too.
Likewise, the alsamixer won't reflect the volume
change of pa. So it is completely disconnected.
If I redefine the softvol from "Master Playback Volume"
to "PCM Playback Volume", then it starts to
reflect the state of the pa volume, but not the
other way around.
And with other drivers, that seemingly use the
softvol too, everything works. But that's a bit
odd, since the driver should have nothing to
do with softvol...

> The entire plugin stack is subject to customisation.
>
OK, thanks for the info.
Then some debugging is a due.

>> So what the real fix do you think of?
> Like I say, I've no idea what the actual problem is so can't really
> comment.
softvol doesn't communicate with pulseaudio,
when snd-pcsp is used. That's all about it. :)
But I'll try to find time for some debugging, thank you.

Re: how to mandate the use of PCM plugin?

[Raymond Yau]

2010/9/28 Stas Sergeev <stsp@aknet.ru>

>  28.09.2010 02:00, Mark Brown wrote:
> > I can't really comment since I've no idea what the problem is; if it's
> > not understood what has gone wrong then some diagnosis will be needed.
> For now, all I can say is that the softvol
> doesn't communicate with pulseaudio when
> snd-pcsp is used. You can alter it, but the
> playback volume won't change. And if you
> run the pulseaudio mixer in parallel, it won't
> reflect the change done by alsamixer too.
>

AFAIK, PA probe "hw" device for mono output profile first .

As snd-pcsp support only mono , PA expect "front" device support stereo so
it cannot create stereo output profile

So it is incorrect to define "front" device to use "hw" without "plug"
plugin  when the pcsp does not support stereo

 http://0pointer.de/blog/projects/decibel-data.html

finally falling back to software for everything that cannot be done in
hardware.

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-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>

> 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>
>>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')