[alsa-devel] how to mandate the use of PCM plugin?
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?
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.
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?
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.
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?
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.
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.
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.
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.
'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
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
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
On 2010-09-28 06:07, Raymond Yau wrote:
2010/9/28 Colin Guthriegmane@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).
2010/9/29 David Henningsson david.henningsson@canonical.com
On 2010-09-28 06:07, Raymond Yau wrote:
2010/9/28 Colin Guthriegmane@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%
On 2010-10-02 04:11, Raymond Yau wrote:
2010/9/29 David Henningssondavid.henningsson@canonical.com
On 2010-09-28 06:07, Raymond Yau wrote:
2010/9/28 Colin Guthriegmane@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....
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 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
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 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
2010/10/4 David Henningsson david.henningsson@canonical.com
On 2010-10-02 04:11, Raymond Yau wrote:
2010/9/29 David Henningssondavid.henningsson@canonical.com
On 2010-09-28 06:07, Raymond Yau wrote:
2010/9/28 Colin Guthriegmane@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....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=eacbb9dba6b4c9...
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
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
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....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
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
On 2010-10-21 06:36, Raymond Yau wrote:
2010/10/4 David Henningssondavid.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).
2010/10/21 David Henningsson david.henningsson@canonical.com
On 2010-10-21 06:36, Raymond Yau wrote:
2010/10/4 David Henningssondavid.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')
participants (6)
-
Clemens Ladisch -
Colin Guthrie -
David Henningsson -
Mark Brown -
Raymond Yau -
Stas Sergeev