[alsa-devel] wrong decibel data?
Hello, I have a laptop with an intel hda audio chipset (STAC92xx)
My problem is that when I put pulseaudio volume to 14% (or less) I can't hear any audio coming from speakers or headphones: in fact the alsamixer volume is set to 0%
I already filed a bug to pulseaudio [1] in which the developers say that this is a common problem which is usually caused by the ALSA audio driver which reports a wrong decibel value.
I just had a discussion with pulseaudio developers in which they told me that if the speakers don't emit any audio when the ALSA volume is 0%, then the correct gain value should be -inf dB (a value lower than -200 for pulseaudio means mute). Unfortunately my card has -48 dB.
They also said that if with -47.25 dB (which is what I get with ALSA volume set to 2%) I can hear audio even if it's very very low, at -48 dB I should still be able to hear something (the scale is logarithmic).
Their request is to change to -200 the gain reported from my card driver when the ALSA volume is set to 0%. Thanks
'Twas brillig, and Nicolo' Chieffo at 02/04/10 21:25 did gyre and gimble:
I just had a discussion with pulseaudio developers in which they told me that if the speakers don't emit any audio when the ALSA volume is 0%, then the correct gain value should be -inf dB (a value lower than -200 for pulseaudio means mute). Unfortunately my card has -48 dB.
They also said that if with -47.25 dB (which is what I get with ALSA volume set to 2%) I can hear audio even if it's very very low, at -48 dB I should still be able to hear something (the scale is logarithmic).
Their request is to change to -200 the gain reported from my card driver when the ALSA volume is set to 0%. Thanks
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
Thanks for getting the ball rolling :)
If any specific debug is needed here, feel free to ask.
Col
I don't think that any specific debug is needed. pulseaudio developers just told that you have to declare -200 dB when the sound is disabled, that's it. Is this a difficult thing to do? which files must be touched?
On Sat, Apr 3, 2010 at 12:09 PM, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and Nicolo' Chieffo at 02/04/10 21:25 did gyre and gimble:
I just had a discussion with pulseaudio developers in which they told me that if the speakers don't emit any audio when the ALSA volume is 0%, then the correct gain value should be -inf dB (a value lower than -200 for pulseaudio means mute). Unfortunately my card has -48 dB.
They also said that if with -47.25 dB (which is what I get with ALSA volume set to 2%) I can hear audio even if it's very very low, at -48 dB I should still be able to hear something (the scale is logarithmic).
Their request is to change to -200 the gain reported from my card driver when the ALSA volume is set to 0%. Thanks
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
Thanks for getting the ball rolling :)
If any specific debug is needed here, feel free to ask.
Col
--
Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/
Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
2010/4/3 Nicolo' Chieffo nicolo.chieffo@gmail.com
I don't think that any specific debug is needed. pulseaudio developers just told that you have to declare -200 dB when the sound is disabled, that's it. Is this a difficult thing to do? which files must be touched?
to proivide dB scale of pulse master volume control of the alsa mixer applications
alsa-plugins/pulse/ctl_pulse.c
Hello, Could you plz confirm, if the ALSA drivers support the stereo format files with 'aplay'?
PS: Iam using the 1.0.5 version
Thanks Swami
Reddy, MR Swami wrote:
Could you plz confirm, if the ALSA drivers support the stereo format files with 'aplay'?
aplay supports stereo files; whether the driver supports this depends on the driver.
I don't know what you problem is, but it's likely that you tried to play a stereo file on a mono device or a mono file on a stereo-only device, and that you used a device name like "hw:0" that disables all automatic format conversions, instead of "default".
Regards, Clemens
2010/4/3 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Nicolo' Chieffo at 02/04/10 21:25 did gyre and gimble:
I just had a discussion with pulseaudio developers in which they told me that if the speakers don't emit any audio when the ALSA volume is 0%, then the correct gain value should be -inf dB (a value lower than -200 for pulseaudio means mute). Unfortunately my card has -48 dB.
They also said that if with -47.25 dB (which is what I get with ALSA volume set to 2%) I can hear audio even if it's very very low, at -48 dB I should still be able to hear something (the scale is logarithmic).
Their request is to change to -200 the gain reported from my card driver when the ALSA volume is set to 0%. Thanks
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
Thanks for getting the ball rolling :)
If any specific debug is needed here, feel free to ask.
Col
if -48dB of alsa volume represent (100-14)% of the volume range of pulseaudio control
i.e. the volume range of pulseaudio is only -63dB , why do you use -200dB ?
2010/4/3 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Nicolo' Chieffo at 02/04/10 21:25 did gyre and gimble:
I just had a discussion with pulseaudio developers in which they told me that if the speakers don't emit any audio when the ALSA volume is 0%, then the correct gain value should be -inf dB (a value lower than -200 for pulseaudio means mute). Unfortunately my card has -48 dB.
They also said that if with -47.25 dB (which is what I get with ALSA volume set to 2%) I can hear audio even if it's very very low, at -48 dB I should still be able to hear something (the scale is logarithmic).
Their request is to change to -200 the gain reported from my card driver when the ALSA volume is set to 0%. Thanks
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
Thanks for getting the ball rolling :)
If any specific debug is needed here, feel free to ask.
Col
--
since PA provide software atten/software gain ,the software atten of 16bits audio is -48dB
I guess the problem is related to PA shift the 0dB point (i.e. the software gain +15dfB to 0dB)
you have to ask PA developer the value of software dB gain provided by the PA server
2010/4/3 Colin Guthrie gmane@colin.guthr.ie
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
Thanks for getting the ball rolling :)
If any specific debug is needed here, feel free to ask.
Col
for debugging , please post the output of alsa-info.sh of your hardware
and output of "amixer -D pulse" when you change the volume control to 0% by "alsamixer -c 0"
2010/4/3 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Nicolo' Chieffo at 02/04/10 21:25 did gyre and gimble:
I just had a discussion with pulseaudio developers in which they told me that if the speakers don't emit any audio when the ALSA volume is 0%, then the correct gain value should be -inf dB (a value lower than -200 for pulseaudio means mute). Unfortunately my card has -48 dB.
They also said that if with -47.25 dB (which is what I get with ALSA volume set to 2%) I can hear audio even if it's very very low, at -48 dB I should still be able to hear something (the scale is logarithmic).
Their request is to change to -200 the gain reported from my card driver when the ALSA volume is set to 0%. Thanks
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
Thanks for getting the ball rolling :)
If any specific debug is needed here, feel free to ask.
Col
--
some sound card may not have hardware volume control ,(e.g. those the mic of those low cost web cam ) which use softvol plugin which has a default -51dB min_dB
do you mean that you also need to change it to -200 dB ?
2010/4/3 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Nicolo' Chieffo at 02/04/10 21:25 did gyre and gimble:
I just had a discussion with pulseaudio developers in which they told me that if the speakers don't emit any audio when the ALSA volume is 0%, then the correct gain value should be -inf dB (a value lower than -200 for pulseaudio means mute). Unfortunately my card has -48 dB.
They also said that if with -47.25 dB (which is what I get with ALSA volume set to 2%) I can hear audio even if it's very very low, at -48 dB I should still be able to hear something (the scale is logarithmic).
Their request is to change to -200 the gain reported from my card driver when the ALSA volume is set to 0%. Thanks
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
Thanks for getting the ball rolling :)
If any specific debug is needed here, feel free to ask.
Col
I don't agree *Lennart Poettering say *"ALSA does not define any reference point for the dB scale it exports in its mixer controls "
For most of the driver with dB scale, the 0dB point is the reference point , the reason is PA developer choose a cubic mapping "It's now cubic, which is supposed to be feel more 'natural'."
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-May/003898.html
Because PA exposes the same volume scale mapping on all hardware.
In 0.9.15 we mapped 0% on the volume scale to -90dB and 100% to 0dB,
in between the mapping between those percentages and the dB scale was linear (i.e. to the effect that we had an overall logarithmic mapping).
This mapping is not particularly well chosen since it gives too much
control over the uninteresting parts below -20dB and too little control over the 'interesting' parts above -20dB. That's why I modified the mapping in PA git. It's now cubic, which is supposed to be feel more 'natural'.
So, coming back to how PA maps those volumes to ALSA: alsamixer will expose
the exact discrete volume steps of the sound card and show dB information just as little help at the side. PA however controls the volume in dB and if the hw doesn't provide the requested volume step we go to the next higher and then attenuate by the remaining factor in software. That way we can provide the same volume range and granularity on all hardware with the same mapping from the UI to the attenuation factor. So basically, while tha mapping from those percentages to the loudness is different in PA and alsamixer, the dB scaling is mostly the same -- except when it is not...
'Twas brillig, and Raymond Yau at 16/04/10 14:48 did gyre and gimble:
2010/4/3 Colin Guthrie gmane@colin.guthr.ie
Sorry for the top post but....
Raymond. Your replies are often very disjoint. I see no relevance to my message here and why you're replying here is beyond me.
It's totally unclear what point you are making and which parts of this message are your comments and which are Lennart's original comments that's you've just pasted in.
What are you trying to say?
Col
I don't agree *Lennart Poettering say *"ALSA does not define any reference point for the dB scale it exports in its mixer controls "
For most of the driver with dB scale, the 0dB point is the reference point , the reason is PA developer choose a cubic mapping "It's now cubic, which is supposed to be feel more 'natural'."
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-May/003898.html
Because PA exposes the same volume scale mapping on all hardware.
In 0.9.15 we mapped 0% on the volume scale to -90dB and 100% to 0dB,
in between the mapping between those percentages and the dB scale was linear (i.e. to the effect that we had an overall logarithmic mapping).
This mapping is not particularly well chosen since it gives too much
control over the uninteresting parts below -20dB and too little control over the 'interesting' parts above -20dB. That's why I modified the mapping in PA git. It's now cubic, which is supposed to be feel more 'natural'.
So, coming back to how PA maps those volumes to ALSA: alsamixer will expose
the exact discrete volume steps of the sound card and show dB information just as little help at the side. PA however controls the volume in dB and if the hw doesn't provide the requested volume step we go to the next higher and then attenuate by the remaining factor in software. That way we can provide the same volume range and granularity on all hardware with the same mapping from the UI to the attenuation factor. So basically, while tha mapping from those percentages to the loudness is different in PA and alsamixer, the dB scaling is mostly the same -- except when it is not...
2010/4/17 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 16/04/10 14:48 did gyre and gimble:
2010/4/3 Colin Guthrie gmane@colin.guthr.ie
Sorry for the top post but....
Raymond. Your replies are often very disjoint. I see no relevance to my message here and why you're replying here is beyond me.
It's totally unclear what point you are making and which parts of this message are your comments and which are Lennart's original comments that's you've just pasted in.
What are you trying to say?
Col
http://pulseaudio.org/ticket/580
Basically, if the signal is completely cut off, then the attenuation is
-inf dB.
you have to sum the dB gain of the SPL of the speaker/headphone when you want to calculate the dB ( sound pressure and the distance )
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you
have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
If any specific debug is needed here, feel free to ask.
Just reply since you still have similar problem , but it seem that you are unwilling to provide info to debug your case , at least you have to provide output of alsa-info.sh even when you have the same/similar h/w ,
do your laptop has the volume knob ?
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-May/003898.html
If pulseaudio provide per-application volume control, why the PA community propose to throw away the volume slider of the application. (i.e. why only allow pavucontrol to change the per-application volume ?
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/6521/focus=6524
Making the application volume sliders control the device volume isn't
good either, because if an application has a volume slider, the natural assumption made by users is that the slider controls only that application's volume.
Solution: throw away volume sliders in applications, and promote centralized volume management with volume applets and hardware controls.
I suggest PA should provide the pre-application volume control for the application too since from the viewpoint of PA when PA have to control all the volume , it is better not allow application to control alsa master volume control. but there is no reason to remove the volume sliders in application
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=*hwmixvolume*/R... http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=hwmixvolume/README
The per-application volume control is quite similar to the per voice volume control of those hardware mixing sound cards , although there are some differences
the per voice volume control of hardware mixing sound card provide digital gain/atten by the DSP ( not those gain/atten of DAC )
http://thread.gmane.org/gmane.linux.alsa.devel/24638/focus=24707
'Twas brillig, and Raymond Yau at 21/04/10 03:32 did gyre and gimble:
2010/4/17 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 16/04/10 14:48 did gyre and gimble:
2010/4/3 Colin Guthrie gmane@colin.guthr.ie
Sorry for the top post but....
Raymond. Your replies are often very disjoint. I see no relevance to my message here and why you're replying here is beyond me.
It's totally unclear what point you are making and which parts of this message are your comments and which are Lennart's original comments that's you've just pasted in.
What are you trying to say?
Col
http://pulseaudio.org/ticket/580
Basically, if the signal is completely cut off, then the attenuation is
-inf dB.
you have to sum the dB gain of the SPL of the speaker/headphone when you want to calculate the dB ( sound pressure and the distance )
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you
have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
If any specific debug is needed here, feel free to ask.
Just reply since you still have similar problem , but it seem that you are unwilling to provide info to debug your case , at least you have to provide output of alsa-info.sh even when you have the same/similar h/w ,
What debug have you asked me for? It's impossible to tell from the vaguely relevant quotations (poorly formatted in email so that only half of the quoted text actually looks like a quote) and random specification sheet snippets you post that you're actually asking for anything at all!
If you want information, ask for it clearly and I'll do my best to answer it.
If pulseaudio provide per-application volume control, why the PA community propose to throw away the volume slider of the application. (i.e. why only allow pavucontrol to change the per-application volume ?
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/6521/focus=6524
That is a discussion, not a statement of intent. As I stated on that thread, I personally disagree with Tanu's position, but if you are interested in this discussion, feel free to join in on that list. It's nothing to do with this thread at all however (it's purely a UI and user expectation of cause + effect), so let's not drag this thread further into the land of obscure tangents.
Making the application volume sliders control the device volume isn't
good either, because if an application has a volume slider, the natural assumption made by users is that the slider controls only that application's volume.
Solution: throw away volume sliders in applications, and promote centralized volume management with volume applets and hardware controls.
I suggest PA should provide the pre-application volume control for the application too since from the viewpoint of PA when PA have to control all the volume , it is better not allow application to control alsa master volume control. but there is no reason to remove the volume sliders in application
I suggest you discuss this issue on the actual thread itself rather than pull it in to a completely different one. I do however think you've missed the point, but like I say that is something to discuss there, not here.
Col
2010/4/21 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 21/04/10 03:32 did gyre and gimble:
2010/4/17 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 16/04/10 14:48 did gyre and gimble:
2010/4/3 Colin Guthrie gmane@colin.guthr.ie
Sorry for the top post but....
Raymond. Your replies are often very disjoint. I see no relevance to my message here and why you're replying here is beyond me.
It's totally unclear what point you are making and which parts of this message are your comments and which are Lennart's original comments that's you've just pasted in.
What are you trying to say?
Col
http://pulseaudio.org/ticket/580
Basically, if the signal is completely cut off, then the attenuation is
-inf dB.
you have to sum the dB gain of the SPL of the speaker/headphone when you want to calculate the dB ( sound pressure and the distance )
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you
have. I've been meaning to get this fixed for a while, but I'm incredibly lazy with certain things that don't bother me practically, so haven't followed it up yet.
If any specific debug is needed here, feel free to ask.
Just reply since you still have similar problem , but it seem that you
are
unwilling to provide info to debug your case , at least you have to
provide
output of alsa-info.sh even when you have the same/similar h/w ,
What debug have you asked me for?
Just output of alsa-info.sh as stated in my previous email
and please confirm that PA provide software gain
It's impossible to tell from the vaguely relevant quotations (poorly formatted in email so that only half of the quoted text actually looks like a quote) and random specification sheet snippets you post that you're actually asking for anything at all!
If you want information, ask for it clearly and I'll do my best to answer it.
If pulseaudio provide per-application volume control, why the PA
community
propose to throw away the volume slider of the application. (i.e. why
only
allow pavucontrol to change the per-application volume ?
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/6521/focus=6524
That is a discussion, not a statement of intent. As I stated on that thread, I personally disagree with Tanu's position, but if you are interested in this discussion, feel free to join in on that list. It's nothing to do with this thread at all however (it's purely a UI and user expectation of cause + effect), so let's not drag this thread further into the land of obscure tangents.
Making the application volume sliders control the device volume isn't
good either, because if an application has a volume slider, the natural assumption made by users is that the slider controls only that
application's
volume.
Solution: throw away volume sliders in applications, and promote
centralized volume management with volume applets and hardware controls.
I suggest PA should provide the pre-application volume control for the application too since from the viewpoint of PA when PA have to control
all
the volume , it is better not allow application to control alsa master volume control. but there is no reason to remove the volume sliders in application
I suggest you discuss this issue on the actual thread itself rather than pull it in to a completely different one. I do however think you've missed the point, but like I say that is something to discuss there, not here.
I just make suggestion only since I don't know whether it is feasible to implement IFACE_PCM in ctl_pulse.c but I strongly recommended PA provide dB scale for the Master Volume control for the pulse device ( alsa-pulse plugin ) in order for the mixer application to provide a more useful info to the user
Col
'Twas brillig, and Raymond Yau at 22/04/10 02:16 did gyre and gimble:
Just output of alsa-info.sh as stated in my previous email
Oh I've only just noticed this reply (prompted by a comment on another related thread).
Apologies, but I'd not seen this request until now.
I attach my alsa-info.sh output.
and please confirm that PA provide software gain
Not sure precisely what you mean by this in this context.
Col
Colin Guthrie wrote:
state.Intel { control.1 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -4650 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value.0 30 value.1 30 }
This is the hardware volume control.
control.11 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 253 value.1 253 }
This is the emulated software volume control that is created by the softvol plugin. This control gets recreated by "alsactl restore" even when the plugin is not running.
Might it be possible that PA is trying to use this, but that it doesn't have any effect because PA is using PCM device hw:0? (Try unloading snd-hda-intel and then deleting that entry from /etc/asound.state.)
Regards, Clemens
'Twas brillig, and Clemens Ladisch at 27/05/10 14:48 did gyre and gimble:
Colin Guthrie wrote:
state.Intel { control.1 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -4650 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value.0 30 value.1 30 }
This is the hardware volume control.
control.11 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 253 value.1 253 }
This is the emulated software volume control that is created by the softvol plugin. This control gets recreated by "alsactl restore" even when the plugin is not running.
Might it be possible that PA is trying to use this, but that it doesn't have any effect because PA is using PCM device hw:0? (Try unloading snd-hda-intel and then deleting that entry from /etc/asound.state.)
PA should play nice with the softvol plugin so I don't think this is the bit that is at fault.
I strongly suspect that the reason has already been correctly identified a while ago, which is that this card considers -48dB silent where as PA assumes this level is -200dB. I believe it was Raymond who pointed out the -48dB level in the HDA spec before on this list.
I'm not sure of the internals, but things do indeed go silent when the volume reaches the magic -48dB mark (which is around the 14% mark with the current cubic mapping).
I suspect that if I were to define infinity to be 48.0 in PA, everything would work nicely.
What I think is then ultimately needed is a way to ensure that everyone sings from the same hymn sheet regarding the real world value of -inf dB.
I was hoping Lennart would have commented on this thread by now, so I'll try and prod him to get some proper input as I'm very much flailing around wildly in the dark!
Col
'Twas brillig, and Colin Guthrie at 27/05/10 15:43 did gyre and gimble:
PA should play nice with the softvol plugin so I don't think this is the bit that is at fault.
I strongly suspect that the reason has already been correctly identified a while ago, which is that this card considers -48dB silent where as PA assumes this level is -200dB. I believe it was Raymond who pointed out the -48dB level in the HDA spec before on this list.
I'm not sure of the internals, but things do indeed go silent when the volume reaches the magic -48dB mark (which is around the 14% mark with the current cubic mapping).
I suspect that if I were to define infinity to be 48.0 in PA, everything would work nicely.
I'm wrong (surprise, surprise!). Changing this value makes very little difference.
FWIW, the -200dB thing is just a work around for systems that do not define INFINITY. On my system this is defined. in bits/inf.h
So the value of 200dB mentioned by Raymond is not actually used generally speaking.
Even if I undef and define INFINITY to be 48, the actual shut down at -48 seems to happen regardless.
Looking at this in more depth, it seems that the problem is such that the Master control of my card controls things down to -46.5dB. Once that has hit 0, the PCM control takes over and goes down to -51dB
It seems that PA's full scale is determined as the multiplication of thse two elements; therefore: -97.5dB.
However as things basically go silent at -48dB, the inclusion of Master and PCM controls represent too large a range.
So either the 48dB of the HDA spec should be split between Master and PCM more evenly, (e.g. 24dB each) or PCM should be removed and Master should just have the full 48dB range. I don't really understand the Master<->PCM relationship, but this is certainly and issue.
So my second guess (having now abandoned the idea of a problem in PA's -inf definition) is that fixing the above, should fix things :)
Col
2010/5/28 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Colin Guthrie at 27/05/10 15:43 did gyre and gimble:
PA should play nice with the softvol plugin so I don't think this is the bit that is at fault.
I strongly suspect that the reason has already been correctly identified a while ago, which is that this card considers -48dB silent where as PA assumes this level is -200dB. I believe it was Raymond who pointed out the -48dB level in the HDA spec before on this list.
if floating point 0.0 is -inf dB , and 1.0 is 0dB ,
0.5 is -6dB , 0.25 is -12 dB , 0.125 is -24dB and 0.0625 is -48dB
how can PA master volume control at 10~15% equivalent to HDA 's -48dB ?
Can you provide the pulseaudio log when you change the volume from 100% to 0% ?
'Twas brillig, and Raymond Yau at 06/06/10 01:12 did gyre and gimble:
2010/5/28 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Colin Guthrie at 27/05/10 15:43 did gyre and gimble:
PA should play nice with the softvol plugin so I don't think this is the bit that is at fault.
I strongly suspect that the reason has already been correctly identified a while ago, which is that this card considers -48dB silent where as PA assumes this level is -200dB. I believe it was Raymond who pointed out the -48dB level in the HDA spec before on this list.
if floating point 0.0 is -inf dB , and 1.0 is 0dB ,
0.5 is -6dB , 0.25 is -12 dB , 0.125 is -24dB and 0.0625 is -48dB
This is just a pure mapping from dB->linear, but as this linear mapping is generally not "natural" there are several different approaches to presenting this to users. In PA, a cubic mapping is used on top of this basic conversion, to map to the percentage scale (0.0 to 1.0 if you like).
So I'm not sure what point you're making by providing these numbers. Can you explain?
how can PA master volume control at 10~15% equivalent to HDA 's -48dB ?
Not sure what you mean here, but I suspect it's the cubic mapping that is confusing you.
Here is the function in PA's pulse/volume.c:
pa_volume_t pa_sw_volume_from_linear(double v) {
if (v <= 0.0) return PA_VOLUME_MUTED;
/* * We use a cubic mapping here, as suggested and discussed here: * * http://www.robotplanet.dk/audio/audio_gui_design/ * http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-May/thread.html#2... * * We make sure that the conversion to linear and back yields the * same volume value! That's why we need the lround() below! */
return (pa_volume_t) lround(cbrt(v) * PA_VOLUME_NORM); }
Can you provide the pulseaudio log when you change the volume from 100% to 0% ?
I can provide the actual log output if you like but here is the output from the following command:
(for i in 100 95 90 85 80 75 70 65 60 55 50 45 40 35 30 25 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0; do echo "============================== $i% =============="; amixer set Master $i%>/dev/null; amixer -c0 get Master; amixer -c0 get PCM; echo "PulseAudio:"; pacmd list-sinks| grep "index: 11" -A 13; done) 2>&1
volume-test.txt
This basically sets the volume (via alsa->pulse plugin, but that's just for convenience!) all the way down to 0. I get more fine grained below 20 as that is the interesting zone.
The output shows the scaling from 100% where both Master and PCM are 0dB, up to the point at around 16% where the Master channel is maxed out at -46.5dB (0%) and PA starts instead manipulating the PCM control to get more of it's range (up until this point PCM was only used to gain more accuracy - i.e. when Master alone did not provide as fine grained a setting as was needed; in this scenario, PA will use the PCM control to get more accuracy and, if needed, it will also use software scaling on top of that: for more info about this works see: http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes).
As you can see from the output, by the time we reach 2%, both Master and PCM are fully maxed out at -46.5dB and -51dB respectively. At this point PA wants a volume of -101.93dB, so that means that -101.93 - (-51+-46.5=-96.5) = -5.43 dB is performed in software.
By 1%, the software component of the reduction increases to -23.47dB to give a total of -119.97dB. By 0% we reach -inf dB
Obviously the fact that the chip basically cuts off any audio when the Master slider hits 0 (or perhaps when the combined volume reaches -48dB - it's hard to tell) doesn't really play nicely with the real value of -inf which we attempt to reach.
I'm not sure where this problem needs to be fixed. Oviously having a Master and PCM slider whose range is far greater than the value of -48dB is pointless. This configuration means that there are numerous "zero point" configurations of the two sliders beyond which any further change in value is useless. So disregarding PA completely, this setup is not ideal.
When PA is used, the value for -inf is actually configured by the system and we attempt to scale to -inf (albeit via a cubic mapping from percentage). If the volume literally cuts out at -48dB when dealing with the h/w mixers, then there is a problem, but by the same token if the -48dB level really is more like the silence we want to represent, then perhaps trying to scale to -inf is pointless in itself and really the range of the scale used in PA should be adjusted.
I don't know enough about this side of things to comment more accurately than this, so when LinuxTag is over, hopefully Lennart can comment a bit on this thread to add his opinions to the mix.
Col
Col
2010/6/7 Colin Guthrie gmane@colin.guthr.ie
if floating point 0.0 is -inf dB , and 1.0 is 0dB ,
0.5 is -6dB , 0.25 is -12 dB , 0.125 is -24dB and 0.0625 is -48dB
This is just a pure mapping from dB->linear, but as this linear mapping is generally not "natural" there are several different approaches to presenting this to users. In PA, a cubic mapping is used on top of this basic conversion, to map to the percentage scale (0.0 to 1.0 if you like).
Seem that my value is still wrong , every -6dB half the volume
so 1.5 is +6dB , 1.0 is 0dB, -6dB is 0.5 , -12 dB is 0.25, -18dB is 0.125, -24dB is 0.0625
if shift 16 bit digital audio data to right by 1 bit is -6dB , -96dB is 0.000015
So I'm not sure what point you're making by providing these numbers. Can you explain?
how can PA master volume control at 10~15% equivalent to HDA 's -48dB ?
Not sure what you mean here, but I suspect it's the cubic mapping that is confusing you.
Here is the function in PA's pulse/volume.c:
pa_volume_t pa_sw_volume_from_linear(double v) {
if (v <= 0.0) return PA_VOLUME_MUTED;
/* * We use a cubic mapping here, as suggested and discussed here: * * http://www.robotplanet.dk/audio/audio_gui_design/ *
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-May/thread.html#2... * * We make sure that the conversion to linear and back yields the * same volume value! That's why we need the lround() below! */
return (pa_volume_t) lround(cbrt(v) * PA_VOLUME_NORM); }
can you provide the forumla for the "Master" volume control of pulse device ? ctl.pulse
there are 65536 steps , where are 0dB , -6dB and -inf dB on this cubic mapping ?
'Twas brillig, and Raymond Yau at 08/06/10 01:47 did gyre and gimble:
Here is the function in PA's pulse/volume.c:
pa_volume_t pa_sw_volume_from_linear(double v) {
if (v <= 0.0) return PA_VOLUME_MUTED;
/* * We use a cubic mapping here, as suggested and discussed here: * * http://www.robotplanet.dk/audio/audio_gui_design/ *
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-May/thread.html#2... * * We make sure that the conversion to linear and back yields the * same volume value! That's why we need the lround() below! */
return (pa_volume_t) lround(cbrt(v) * PA_VOLUME_NORM); }
can you provide the forumla for the "Master" volume control of pulse device ? ctl.pulse
there are 65536 steps , where are 0dB , -6dB and -inf dB on this cubic mapping ?
Well 0 dB and -inf dB are obvious: 100% and 0% respectively.
-6dB is about 80%:
1. Convert to Linear: 10 ^ (-6 / 20.0) = 10 ^ -0.3 = 0.501187 2. Cube Root: 0.7943
Here is the code from volume.c that does this (combined with the function already pasted above). It's probably easier just to follow the code rather than have me describe it (no doubt poorly!):
static double dB_to_linear(double v) { return pow(10.0, v / 20.0); }
pa_volume_t pa_sw_volume_from_dB(double dB) { if (isinf(dB) < 0 || dB <= PA_DECIBEL_MININFTY) return PA_VOLUME_MUTED;
return pa_sw_volume_from_linear(dB_to_linear(dB)); }
The final stage in pa_sw_volume_from_linear() (the * by PA_VOLUME_NORM and the lround()) is just converting to PA's own internal representation.
HTHs
Just for clarity, the reverse of for my approximate cut off at 16% would be: 16% = 0.16 0.16 ^ 3 = 0.004096 20 * log(0.004096) = -47.75dB
Col
2010/6/8 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 08/06/10 01:47 did gyre and gimble:
Here is the function in PA's pulse/volume.c:
pa_volume_t pa_sw_volume_from_linear(double v) {
if (v <= 0.0) return PA_VOLUME_MUTED;
/* * We use a cubic mapping here, as suggested and discussed here: * * http://www.robotplanet.dk/audio/audio_gui_design/ *
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-May/thread.html#2...
* * We make sure that the conversion to linear and back yields the * same volume value! That's why we need the lround() below! */return (pa_volume_t) lround(cbrt(v) * PA_VOLUME_NORM); }
can you provide the forumla for the "Master" volume control of pulse
device
? ctl.pulse
there are 65536 steps , where are 0dB , -6dB and -inf dB on this cubic mapping ?
Well 0 dB and -inf dB are obvious: 100% and 0% respectively.
-6dB is about 80%:
- Convert to Linear: 10 ^ (-6 / 20.0) = 10 ^ -0.3 = 0.501187
- Cube Root: 0.7943
Here is the code from volume.c that does this (combined with the function already pasted above). It's probably easier just to follow the code rather than have me describe it (no doubt poorly!):
static double dB_to_linear(double v) { return pow(10.0, v / 20.0); }
pa_volume_t pa_sw_volume_from_dB(double dB) { if (isinf(dB) < 0 || dB <= PA_DECIBEL_MININFTY) return PA_VOLUME_MUTED;
return pa_sw_volume_from_linear(dB_to_linear(dB)); }
The final stage in pa_sw_volume_from_linear() (the * by PA_VOLUME_NORM and the lround()) is just converting to PA's own internal representation.
HTHs
Just for clarity, the reverse of for my approximate cut off at 16% would be: 16% = 0.16 0.16 ^ 3 = 0.004096 20 * log(0.004096) = -47.75dB
Can you explain how PA handle the volume controls of ac97 codec ?
PCM -34.5dB to +*12* dB Master -46.5dB to 0dB
The total dB range (PCM + MASTER) is -81dB to +*12*dB
Most user concern about recording without distrotion. (i.e. best result when Capture Volume at 0dB , PCM and Master Volume at 0dB ) and they need where are 0dB points
'Twas brillig, and Raymond Yau at 10/06/10 04:16 did gyre and gimble:
Can you explain how PA handle the volume controls of ac97 codec ?
PCM -34.5dB to +*12* dB Master -46.5dB to 0dB
The total dB range (PCM + MASTER) is -81dB to +*12*dB
Most user concern about recording without distrotion. (i.e. best result when Capture Volume at 0dB , PCM and Master Volume at 0dB ) and they need where are 0dB points
I'm not 100% sure how this is handled, but I know it's not ignored. You'll have to ask Lennart directly or dig in the code to see for sure.
Col
2010/6/11 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 10/06/10 04:16 did gyre and gimble:
Can you explain how PA handle the volume controls of ac97 codec ?
PCM -34.5dB to +*12* dB Master -46.5dB to 0dB
The total dB range (PCM + MASTER) is -81dB to +*12*dB
Most user concern about recording without distrotion. (i.e. best result
when
Capture Volume at 0dB , PCM and Master Volume at 0dB ) and they need
where
are 0dB points
I'm not 100% sure how this is handled, but I know it's not ignored. You'll have to ask Lennart directly or dig in the code to see for sure.
Col
- 顯示引用文字 - since the master volume control of ac97 is 1.5 dB per step
using the following code to test snd_mixer_selem_set_playback_dB() with 0.5dB
- 顯示引用文字 - for (v= db_min-100; v<=db_max+100; v+=50 ) { for (c=0; c<1; c++ ) { value=v; if (snd_mixer_selem_set_playback_ - 顯示引用文字 - dB(elem, c, value, +1) == 0) { if ( snd_mixer_selem_get_playback_dB(elem, c, &value) == 0 ) printf("set %3.2f dB get %3.2f dB\n",v/100.0,value/100.0); } else printf("fail to set %3.2f dB\n",v/100.0); }; };
Master playback min=0 max=31 playback dB min -46.50 dB db max 0.00 dB
set -47.50 dB get -46.50 dB set -47.00 dB get -46.50 dB set -46.50 dB get -46.50 dB set -46.00 dB get -46.50 dB set -45.50 dB get -46.50 dB set -45.00 dB get -45.00 dB set -44.50 dB get -45.00 dB set -44.00 dB get -45.00 dB set -43.50 dB get -43.50 dB set -43.00 dB get -43.50 dB set -42.50 dB get -43.50 dB set -42.00 dB get -42.00 dB set -41.50 dB get -42.00 dB set -41.00 dB get -42.00 dB set -40.50 dB get -40.50 dB set -40.00 dB get -40.50 dB set -39.50 dB get -40.50 dB set -39.00 dB get -39.00 dB set -38.50 dB get -39.00 dB set -38.00 dB get -39.00 dB set -37.50 dB get -37.50 dB set -37.00 dB get -37.50 dB set -36.50 dB get -37.50 dB set -36.00 dB get -36.00 dB set -35.50 dB get -36.00 dB set -35.00 dB get -36.00 dB set -34.50 dB get -34.50 dB set -34.00 dB get -34.50 dB set -33.50 dB get -34.50 dB set -33.00 dB get -33.00 dB set -32.50 dB get -33.00 dB set -32.00 dB get -33.00 dB set -31.50 dB get -31.50 dB set -31.00 dB get -31.50 dB set -30.50 dB get -31.50 dB set -30.00 dB get -30.00 dB set -29.50 dB get -30.00 dB set -29.00 dB get -30.00 dB set -28.50 dB get -28.50 dB set -28.00 dB get -28.50 dB set -27.50 dB get -28.50 dB set -27.00 dB get -27.00 dB set -26.50 dB get -27.00 dB set -26.00 dB get -27.00 dB set -25.50 dB get -25.50 dB set -25.00 dB get -25.50 dB set -24.50 dB get -25.50 dB set -24.00 dB get -24.00 dB set -23.50 dB get -24.00 dB set -23.00 dB get -24.00 dB set -22.50 dB get -22.50 dB set -22.00 dB get -22.50 dB set -21.50 dB get -22.50 dB set -21.00 dB get -21.00 dB set -20.50 dB get -21.00 dB set -20.00 dB get -21.00 dB set -19.50 dB get -19.50 dB set -19.00 dB get -19.50 dB set -18.50 dB get -19.50 dB set -18.00 dB get -18.00 dB set -17.50 dB get -18.00 dB set -17.00 dB get -18.00 dB set -16.50 dB get -16.50 dB set -16.00 dB get -16.50 dB set -15.50 dB get -16.50 dB set -15.00 dB get -15.00 dB set -14.50 dB get -15.00 dB set -14.00 dB get -15.00 dB set -13.50 dB get -13.50 dB set -13.00 dB get -13.50 dB set -12.50 dB get -13.50 dB set -12.00 dB get -12.00 dB set -11.50 dB get -12.00 dB set -11.00 dB get -12.00 dB set -10.50 dB get -10.50 dB set -10.00 dB get -10.50 dB set -9.50 dB get -10.50 dB set -9.00 dB get -9.00 dB set -8.50 dB get -9.00 dB set -8.00 dB get -9.00 dB set -7.50 dB get -7.50 dB set -7.00 dB get -7.50 dB set -6.50 dB get -7.50 dB set -6.00 dB get -6.00 dB set -5.50 dB get -6.00 dB set -5.00 dB get -6.00 dB set -4.50 dB get -4.50 dB set -4.00 dB get -4.50 dB set -3.50 dB get -4.50 dB set -3.00 dB get -3.00 dB set -2.50 dB get -3.00 dB set -2.00 dB get -3.00 dB set -1.50 dB get -1.50 dB set -1.00 dB get -1.50 dB set -0.50 dB get -1.50 dB set 0.00 dB get 0.00 dB set 0.50 dB get 0.00 dB set 1.00 dB get 0.00 dB
Compared with the result by voltest.c of pulseaudio-0.9.13
./voltest Volume: 0; percent: 0%; decibel -inf; linear = 0.00; volume(decibel): 0; volume(linear): 0 Volume: 256; percent: 0%; decibel -59.77; linear = 0.00; volume(decibel): 256; volume(linear): 256 Volume: 512; percent: 0%; decibel -59.53; linear = 0.00; volume(decibel): 512; volume(linear): 512 Volume: 768; percent: 1%; decibel -59.30; linear = 0.00; volume(decibel): 768; volume(linear): 768 Volume: 1024; percent: 1%; decibel -59.06; linear = 0.00; volume(decibel): 1024; volume(linear): 1024 Volume: 1280; percent: 1%; decibel -58.83; linear = 0.00; volume(decibel): 1280; volume(linear): 1280 ...
Volume: 6656; percent: 10%; decibel -53.91; linear = 0.00; volume(decibel): 6656; volume(linear): 6656 Volume: 6912; percent: 10%; decibel -53.67; linear = 0.00; volume(decibel): 6912; volume(linear): 6912 Volume: 7168; percent: 10%; decibel -53.44; linear = 0.00; volume(decibel): 7168; volume(linear): 7168
...
Volume: 9216; percent: 14%; decibel -51.56; linear = 0.00; volume(decibel): 9216; volume(linear): 9216 Volume: 9472; percent: 14%; decibel -51.33; linear = 0.00; volume(decibel): 9472; volume(linear): 9472 Volume: 9728; percent: 14%; decibel -51.09; linear = 0.00; volume(decibel): 9728; volume(linear): 9728 Volume: 9984; percent: 15%; decibel -50.86; linear = 0.00; volume(decibel): 9984; volume(linear): 9984 Volume: 10240; percent: 15%; decibel -50.62; linear = 0.00; volume(decibel): 10240; volume(linear): 10240 Volume: 10496; percent: 16%; decibel -50.39; linear = 0.00; volume(decibel): 10496; volume(linear): 10496 Volume: 10752; percent: 16%; decibel -50.16; linear = 0.00; volume(decibel): 10752; volume(linear): 10752 Volume: 11008; percent: 16%; decibel -49.92; linear = 0.00; volume(decibel): 11008; volume(linear): 11008
...
Volume: 15872; percent: 24%; decibel -45.47; linear = 0.01; volume(decibel): 15872; volume(linear): 15872 Volume: 16128; percent: 24%; decibel -45.23; linear = 0.01; volume(decibel): 16128; volume(linear): 16128 Volume: 16384; percent: 25%; decibel -45.00; linear = 0.01; volume(decibel): 16384; volume(linear): 16384 Volume: 16640; percent: 25%; decibel -44.77; linear = 0.01; volume(decibel): 16640; volume(linear): 16640 Volume: 16896; percent: 25%; decibel -44.53; linear = 0.01; volume(decibel): 16896; volume(linear): 16896
...
Volume: 32000; percent: 48%; decibel -30.70; linear = 0.03; volume(decibel): 32000; volume(linear): 32000 Volume: 32256; percent: 49%; decibel -30.47; linear = 0.03; volume(decibel): 32256; volume(linear): 32256 Volume: 32512; percent: 49%; decibel -30.23; linear = 0.03; volume(decibel): 32512; volume(linear): 32512 Volume: 32768; percent: 50%; decibel -30.00; linear = 0.03; volume(decibel): 32768; volume(linear): 32768 Volume: 33024; percent: 50%; decibel -29.77; linear = 0.03; volume(decibel): 33024; volume(linear): 33024 Volume: 33280; percent: 50%; decibel -29.53; linear = 0.03; volume(decibel): 33280; volume(linear): 33280 ...
Volume: 64512; percent: 98%; decibel -0.94; linear = 0.90; volume(decibel): 64512; volume(linear): 64512 Volume: 64768; percent: 98%; decibel -0.70; linear = 0.92; volume(decibel): 64768; volume(linear): 64768 Volume: 65024; percent: 99%; decibel -0.47; linear = 0.95; volume(decibel): 65024; volume(linear): 65024 Volume: 65280; percent: 99%; decibel -0.23; linear = 0.97; volume(decibel): 65280; volume(linear): 65280 Volume: 65536; percent: 100%; decibel 0.00; linear = 1.00; volume(decibel): 65536; volume(linear): 65536 Volume: 65792; percent: 100%; decibel 0.23; linear = 1.03; volume(decibel): 65792; volume(linear): 65792 Volume: 66048; percent: 100%; decibel 0.47; linear = 1.06; volume(decibel): 66048; volume(linear): 66048
..
Volume: 98048; percent: 149%; decibel 29.77; linear = 30.78; volume(decibel): 98048; volume(linear): 98048 Volume: 98304; percent: 150%; decibel 30.00; linear = 31.62; volume(decibel): 98304; volume(linear): 98304 Volume: 98560; percent: 150%; decibel 30.23; linear = 32.49; volume(decibel): 98560; volume(linear): 98560 Volume: 98816; percent: 150%; decibel 30.47; linear = 33.38; volume(decibel): 98816; volume(linear): 98816
...
volume(linear): 130560 Volume: 130816; percent: 199%; decibel 59.77; linear = 973.38; volume(decibel): 130816; volume(linear): 130816 Volume: 131072; percent: 200%; decibel 60.00; linear = 1000.00; volume(decibel): 131072; volume(linear): 131072
can you explain why PA voltest can set dB better than hardware can support ( ac97 only 1.5dB per step ) ?
On Thu, 10.06.10 17:11, Colin Guthrie (gmane@colin.guthr.ie) wrote:
'Twas brillig, and Raymond Yau at 10/06/10 04:16 did gyre and gimble:
Can you explain how PA handle the volume controls of ac97 codec ?
PCM -34.5dB to +*12* dB Master -46.5dB to 0dB
The total dB range (PCM + MASTER) is -81dB to +*12*dB
Most user concern about recording without distrotion. (i.e. best result when Capture Volume at 0dB , PCM and Master Volume at 0dB ) and they need where are 0dB points
I'm not 100% sure how this is handled, but I know it's not ignored. You'll have to ask Lennart directly or dig in the code to see for sure.
If the ALSA volume range is -x dB to +y dB, then the PA volume range will be -x-y dB to 0dB (i.e. shifted by -y dB). On top of that most volume controls should then mark the ALSA 0dB point as "base" volume on the slider, at what PA then calls -y dB.
That way we will expose 0dB as maximum hw amplitude uniformly on all sound cards and have a special point on the slider that is hinted to be the "comfort" point.
This is all explained on http://pulseaudio.org/wiki/WritingVolumeControlUIs#BaseVolumes
Lennart
2010/6/13 Lennart Poettering mznyfn@0pointer.de
On Thu, 10.06.10 17:11, Colin Guthrie (gmane@colin.guthr.ie) wrote:
'Twas brillig, and Raymond Yau at 10/06/10 04:16 did gyre and gimble:
Can you explain how PA handle the volume controls of ac97 codec ?
PCM -34.5dB to +*12* dB Master -46.5dB to 0dB
The total dB range (PCM + MASTER) is -81dB to +*12*dB
Most user concern about recording without distrotion. (i.e. best result
when
Capture Volume at 0dB , PCM and Master Volume at 0dB ) and they need
where
are 0dB points
I'm not 100% sure how this is handled, but I know it's not ignored. You'll have to ask Lennart directly or dig in the code to see for sure.
If the ALSA volume range is -x dB to +y dB, then the PA volume range will be -x-y dB to 0dB (i.e. shifted by -y dB). On top of that most volume controls should then mark the ALSA 0dB point as "base" volume on the slider, at what PA then calls -y dB.
That way we will expose 0dB as maximum hw amplitude uniformly on all sound cards and have a special point on the slider that is hinted to be the "comfort" point.
This is all explained on http://pulseaudio.org/wiki/WritingVolumeControlUIs#BaseVolumes
shifted +12dB to 0dB is completely wrong
+12dB is 4.00 if 0dB is 1.0 (floating point )
you can performed clubsoda 's experiement as in https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/581650
"This is important because if I use those maximum settings and play any
audio which peaks above -12dB, the output will clip and sound distorted."
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM" volume above 0dB
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM" volume above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
IMO this is a good improvement for usability.
Col
2010/6/14 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM"
volume
above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
IMO this is a good improvement for usability.
Col
This is bug in pulseaudio in dB calculation because it shift the ALSA 's dB value to PA 's own dB value
I guess none of PA developers has AC97 sound card
2010/6/14 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM"
volume
above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
IMO this is a good improvement for usability.
Col
The correct way is to provide the real ALSA 's 0dB point (Playback volume) for the user of AC97 sound card so that they can record without any distortion using line in with the loopback cable connected to line out.
'Twas brillig, and Raymond Yau at 14/06/10 09:45 did gyre and gimble:
2010/6/14 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM"
volume
above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
IMO this is a good improvement for usability.
Col
The correct way is to provide the real ALSA 's 0dB point (Playback volume) for the user of AC97 sound card so that they can record without any distortion using line in with the loopback cable connected to line out.
Raymond, can you please, please stop replying to messages multiple times. It makes threads extremely hard to follow and makes replying to your points consistently next to impossible.
_From Lennarts description, the 0dB point (according to alsa) IS the base volume and thus is shown to the user as such. Am I missing something?
The fact that the 0dB point is shifted is fairly irrelevant to the user.
Col
On Mon, 14.06.10 16:45, Raymond Yau (superquad.vortex2@gmail.com) wrote:
The correct way is to provide the real ALSA 's 0dB point (Playback volume) for the user of AC97 sound card so that they can record without any distortion using line in with the loopback cable connected to line out.
Jeez, man, I explained that in my original reply.
If I may quote myself:
'On top of that most volume controls should then mark the ALSA 0dB point as "base" volume on the slider, at what PA then calls -y dB.
That way we will expose 0dB as maximum hw amplitude uniformly on all sound cards and have a special point on the slider that is hinted to be the "comfort" point.
This is all explained on http://pulseaudio.org/wiki/WritingVolumeControlUIs#BaseVolumes'
See? It's all explained there. We still show the ALSA 0dB point on our sliders, we just don't call it "0dB" but "base volume".
Lennart
On 14 June 2010 09:33, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM" volume above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
What do you mean. If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
2010/6/14 James Courtier-Dutton james.dutton@gmail.com
On 14 June 2010 09:33, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM"
volume
above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
What do you mean. If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
The base volume seem to be the software 0dB point , (no software gain/atten), but the user want the hardware 0dB point (no hardware gain/atten if the hardware can provide hardware gain
This hardware 0dB point is extremely important when you want to record using line in and line out
On 14 June 2010 10:54, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/6/14 James Courtier-Dutton james.dutton@gmail.com
If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
The base volume seem to be the software 0dB point , (no software gain/atten), but the user want the hardware 0dB point (no hardware gain/atten if the hardware can provide hardware gain
This hardware 0dB point is extremely important when you want to record using line in and line out
alsamixer gives the hardware 0dB point.
2010/6/14 James Courtier-Dutton james.dutton@gmail.com
On 14 June 2010 10:54, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/6/14 James Courtier-Dutton james.dutton@gmail.com
If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
The base volume seem to be the software 0dB point , (no software gain/atten), but the user want the hardware 0dB point (no hardware gain/atten if the hardware can provide hardware gain
This hardware 0dB point is extremely important when you want to record
using
line in and line out
alsamixer gives the hardware 0dB point.
you are right ,
For ac97 Base volume is the real hardware 0dB point of PCM volume, and Volume NORM is just the max_dB of +12dB which PA labeled it as 100% aka 0dB aka Volume NORM
For HDA , there is no yellow region because max_dB is 0dB , Base Volume and NORM is at the same point
http://en.wikipedia.org/wiki/Line_level
How can I get distortion free recording by line in of ac97 sound connected to line out of HDA onborad and vice versa ?
http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders
On Mon, 14.06.10 17:54, Raymond Yau (superquad.vortex2@gmail.com) wrote:
The base volume seem to be the software 0dB point , (no software gain/atten), but the user want the hardware 0dB point (no hardware gain/atten if the hardware can provide hardware gain
jeez man, this is nonsense.
In PA we call the max hw amplification 0dB. And then we extend things both ways in software. And finally we mark the ALSA 0dB spot (i.e. the *hardware* 0dB spot) as "base volume".
There is nothing lost here.
And you get a cookie if you read this:
http://pulseaudio.org/wiki/WritingVolumeControlUIs#BaseVolumes
and this:
http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders
And then you'll notice that we actually thought about hw and sw volume ranges quite a bit and nothing is lost. For example, our recommended color-coded UI will mark the ALSA 0dB spot with a color transition from green to yellow, to give the user an idea that things get worse beyond that point, even if he doesn't understand dB or hw or sw volumes.
Please, just drop this thread now, and just read the wiki. Thanks.
Lennart
'Twas brillig, and James Courtier-Dutton at 14/06/10 09:56 did gyre and gimble:
On 14 June 2010 09:33, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM" volume above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
What do you mean. If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
But it doesn't hide it. It's shown very clearly in the volume control GUIs as the Base Volume.
Do you really think that most users look at the sliders to find the 0dB point? Does gnome-alsa-mixer (the old one) expose this information? No. Does kmix? No. So the vast, vast majority of users do not know where the 0dB point is unless they use alsamixer.... and even if the user is advanced enough to use alsamixer, then I'd still say a proportion of users are just looking at how far up the slider is rather than looking specifically for 0dB.
So I'd argue the exact opposite of your claim. That with the base volume clearly presented in the GUI, the h/w 0dB spot is much, much more obvious to the vast majority of users.
I really think this is a vast improvement over a complex balancing act of getting two different sliders setup to get distortion free audio!
Col
Caveat: I've not yet made kmix show the base volume, so it still suffers from the problem of masking this important information from the user.
On 14 June 2010 11:22, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and James Courtier-Dutton at 14/06/10 09:56 did gyre and gimble:
If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
But it doesn't hide it. It's shown very clearly in the volume control GUIs as the Base Volume.
Do you really think that most users look at the sliders to find the 0dB point? Does gnome-alsa-mixer (the old one) expose this information? No. Does kmix? No. So the vast, vast majority of users do not know where the 0dB point is unless they use alsamixer.... and even if the user is advanced enough to use alsamixer, then I'd still say a proportion of users are just looking at how far up the slider is rather than looking specifically for 0dB.
So I'd argue the exact opposite of your claim. That with the base volume clearly presented in the GUI, the h/w 0dB spot is much, much more obvious to the vast majority of users.
I really think this is a vast improvement over a complex balancing act of getting two different sliders setup to get distortion free audio!
Col
One has very different problems with capture than one does with playback. With capture it is important to identify which are analog controls (applied to the analog part of the circuit) and which are digital controls (applied to the digital part of the circuit) So, for capture one might wish to adjust the analog control so that the signal going into the ADC is a suitable level, but once the signal is digital, one should really not adjust it further, and just record what you have. If one was to combine these two capture controls in one PA control, it would just be wrong.
I think there is some indication with the name of the control. It sometimes has "Analog" or "Digital" attached to it. I think this would be better if alsa reported the "Analog" or "Digital" as meta data, like the dB Scales. PA could then make more informed decisions for capture. I.e. only display the "Analog" controls, and hide the digital ones, setting them to 0dB. That would provide the most distortion free capture. I think it would also be useful if the alsa driver also reported meta data indicating how the controls are connected together, because then PA would have even more information to make better decisions. For example, USB audio devices have this information, but it is not sent to user space.
'Twas brillig, and James Courtier-Dutton at 14/06/10 11:46 did gyre and gimble:
On 14 June 2010 11:22, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and James Courtier-Dutton at 14/06/10 09:56 did gyre and gimble:
If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
But it doesn't hide it. It's shown very clearly in the volume control GUIs as the Base Volume.
Do you really think that most users look at the sliders to find the 0dB point? Does gnome-alsa-mixer (the old one) expose this information? No. Does kmix? No. So the vast, vast majority of users do not know where the 0dB point is unless they use alsamixer.... and even if the user is advanced enough to use alsamixer, then I'd still say a proportion of users are just looking at how far up the slider is rather than looking specifically for 0dB.
So I'd argue the exact opposite of your claim. That with the base volume clearly presented in the GUI, the h/w 0dB spot is much, much more obvious to the vast majority of users.
I really think this is a vast improvement over a complex balancing act of getting two different sliders setup to get distortion free audio!
Col
One has very different problems with capture than one does with playback. With capture it is important to identify which are analog controls (applied to the analog part of the circuit) and which are digital controls (applied to the digital part of the circuit) So, for capture one might wish to adjust the analog control so that the signal going into the ADC is a suitable level, but once the signal is digital, one should really not adjust it further, and just record what you have. If one was to combine these two capture controls in one PA control, it would just be wrong.
I think there is some indication with the name of the control. It sometimes has "Analog" or "Digital" attached to it. I think this would be better if alsa reported the "Analog" or "Digital" as meta data, like the dB Scales. PA could then make more informed decisions for capture. I.e. only display the "Analog" controls, and hide the digital ones, setting them to 0dB. That would provide the most distortion free capture. I think it would also be useful if the alsa driver also reported meta data indicating how the controls are connected together, because then PA would have even more information to make better decisions. For example, USB audio devices have this information, but it is not sent to user space.
Sounds like that would actually fit in with the current logic (correct me if I'm wrong). PA adjusts multiple sliders in a left-to-right fashion, trying to achieve the ultimate volume the user has requested by setting the left most first and checking if it's "accurate enough". If it is, then it stops there, but if not then it tries to adjust the control to the right. This is repeated until we are "accurate enough" with any further adjustements made in software if needed.
If all the analog controls are lined up to the left followed by all the digital controls to the right, then the goal of "leaving the digital controls alone if at all possible" would be a by product (I think).
At present Master will always be left most, and PCM will always sit to the right of it.
In addition to Lennart's previously posted link on Volume Control GUIs (for the lazyweb: http://pulseaudio.org/wiki/WritingVolumeControlUIs), this approach is explained here: http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes
Col
On Monday 14 June 2010 11:46, James Courtier-Dutton wrote:
On 14 June 2010 11:22, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and James Courtier-Dutton at 14/06/10 09:56 did gyre and
gimble:
If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
But it doesn't hide it. It's shown very clearly in the volume control GUIs as the Base Volume.
Do you really think that most users look at the sliders to find the 0dB point? Does gnome-alsa-mixer (the old one) expose this information? No. Does kmix? No. So the vast, vast majority of users do not know where the 0dB point is unless they use alsamixer.... and even if the user is advanced enough to use alsamixer, then I'd still say a proportion of users are just looking at how far up the slider is rather than looking specifically for 0dB.
So I'd argue the exact opposite of your claim. That with the base volume clearly presented in the GUI, the h/w 0dB spot is much, much more obvious to the vast majority of users.
I really think this is a vast improvement over a complex balancing act of getting two different sliders setup to get distortion free audio!
Col
One has very different problems with capture than one does with playback. With capture it is important to identify which are analog controls (applied to the analog part of the circuit) and which are digital controls (applied to the digital part of the circuit) So, for capture one might wish to adjust the analog control so that the signal going into the ADC is a suitable level, but once the signal is digital, one should really not adjust it further, and just record what you have. If one was to combine these two capture controls in one PA control, it would just be wrong.
I think there is some indication with the name of the control. It sometimes has "Analog" or "Digital" attached to it. I think this would be better if alsa reported the "Analog" or "Digital" as meta data, like the dB Scales. PA could then make more informed decisions for capture. I.e. only display the "Analog" controls, and hide the digital ones, setting them to 0dB. That would provide the most distortion free capture. I think it would also be useful if the alsa driver also reported meta data indicating how the controls are connected together, because then PA would have even more information to make better decisions. For example, USB audio devices have this information, but it is not sent to user space.
I tried unsuccessfully to argue the importance of the distinction between analogue and digital gain controls for capture some time ago in respect of ice1712 based cards fitted with 24-bit AK4524 ADAC chips (or something similar). The chip provides analogue gain pre-ADC, and software attenuation post-ADC. They are however set via a single register, which prevents needless gain+attenuation. Originally they were exposed as 2 separate (but interacting) controls, giving the user the ability to set true '0dB' no-gain-no-software-attenuation point (for pro use). The proposal was made to merge into a single control, and my view against did not prevail. Thus from 1.0.14 the analogue and digital controls portions are indistinguishable on this card, unless you happen to know the 'magic number' that is the value corresponding to the transition from analogue to digital on the scale.
If a mixer app were unknowingly to consider the full-scale value to be the normal operating point, and scale from there, the results would be poor.
Alan
2010/6/14 James Courtier-Dutton james.dutton@gmail.com
On 14 June 2010 11:22, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and James Courtier-Dutton at 14/06/10 09:56 did gyre and gimble:
If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
But it doesn't hide it. It's shown very clearly in the volume control GUIs as the Base Volume.
Do you really think that most users look at the sliders to find the 0dB point? Does gnome-alsa-mixer (the old one) expose this information? No. Does kmix? No. So the vast, vast majority of users do not know where the 0dB point is unless they use alsamixer.... and even if the user is advanced enough to use alsamixer, then I'd still say a proportion of users are just looking at how far up the slider is rather than looking specifically for 0dB.
So I'd argue the exact opposite of your claim. That with the base volume clearly presented in the GUI, the h/w 0dB spot is much, much more obvious to the vast majority of users.
I really think this is a vast improvement over a complex balancing act of getting two different sliders setup to get distortion free audio!
Col
One has very different problems with capture than one does with playback. With capture it is important to identify which are analog controls (applied to the analog part of the circuit) and which are digital controls (applied to the digital part of the circuit) So, for capture one might wish to adjust the analog control so that the signal going into the ADC is a suitable level, but once the signal is digital, one should really not adjust it further, and just record what you have. If one was to combine these two capture controls in one PA control, it would just be wrong.
The AC97 recording from line-in problem seem not related to capture gain since you can set capture volume to 0dB
The HDA 's "PCM" softvol plugin is different from AC97 "PCM" Playback volume
But you can change the softvol plugin to add gain to emulate the clipping in software side if PA developers did not have ac97 sound card ( clipping occur in hardware side )
/usr/share/alsa/cards/HDA-Intel.conf
HDA-Intel.pcm.front.0 { @args [ CARD ] @args.CARD { type string } type softvol slave.pcm { type hw card $CARD } control { name "PCM Playback Volume" card $CARD } + min_dB -46.5 + max_dB 12.0 + resolution 32 }
'Twas brillig, and Raymond Yau at 14/06/10 13:36 did gyre and gimble:
2010/6/14 James Courtier-Dutton james.dutton@gmail.com
On 14 June 2010 11:22, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and James Courtier-Dutton at 14/06/10 09:56 did gyre and gimble:
If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
But it doesn't hide it. It's shown very clearly in the volume control GUIs as the Base Volume.
Do you really think that most users look at the sliders to find the 0dB point? Does gnome-alsa-mixer (the old one) expose this information? No. Does kmix? No. So the vast, vast majority of users do not know where the 0dB point is unless they use alsamixer.... and even if the user is advanced enough to use alsamixer, then I'd still say a proportion of users are just looking at how far up the slider is rather than looking specifically for 0dB.
So I'd argue the exact opposite of your claim. That with the base volume clearly presented in the GUI, the h/w 0dB spot is much, much more obvious to the vast majority of users.
I really think this is a vast improvement over a complex balancing act of getting two different sliders setup to get distortion free audio!
Col
One has very different problems with capture than one does with playback. With capture it is important to identify which are analog controls (applied to the analog part of the circuit) and which are digital controls (applied to the digital part of the circuit) So, for capture one might wish to adjust the analog control so that the signal going into the ADC is a suitable level, but once the signal is digital, one should really not adjust it further, and just record what you have. If one was to combine these two capture controls in one PA control, it would just be wrong.
The AC97 recording from line-in problem seem not related to capture gain since you can set capture volume to 0dB
The HDA 's "PCM" softvol plugin is different from AC97 "PCM" Playback volume
But you can change the softvol plugin to add gain to emulate the clipping in software side if PA developers did not have ac97 sound card ( clipping occur in hardware side )
/usr/share/alsa/cards/HDA-Intel.conf
HDA-Intel.pcm.front.0 { @args [ CARD ] @args.CARD { type string } type softvol slave.pcm { type hw card $CARD } control { name "PCM Playback Volume" card $CARD }
min_dB -46.5max_dB 12.0resolution 32}
I've made this change on my system and while previously my UI had no "Base Volume" displayed (because all my "h/w" (I include softvol in that) controls had their dB value >0.
Now that this change is live, I have a base volume present in my GUI (at around the 64% mark with the cubic scale we've already discussed). When I set my volume ot the base volume, the h/w controls are all set to 0dB which is exactly as expected.
I fail to see the point here? The base volume is clearly exposed to the as the recommended point on the scale at which no clipping occurs.
I really don't get where your complaint is.
Col
On 14 June 2010 15:17, Colin Guthrie gmane@colin.guthr.ie wrote:
I've made this change on my system and while previously my UI had no "Base Volume" displayed (because all my "h/w" (I include softvol in that) controls had their dB value >0.
Now that this change is live, I have a base volume present in my GUI (at around the 64% mark with the cubic scale we've already discussed). When I set my volume ot the base volume, the h/w controls are all set to 0dB which is exactly as expected.
I fail to see the point here? The base volume is clearly exposed to the as the recommended point on the scale at which no clipping occurs.
I really don't get where your complaint is.
Well, if you can define "Volume" in a way that lets you understand this then fine. For me, all these controls are not adjusting "Volume", they are adjusting "Gain", so why are they even called "Base Volume".
'Twas brillig, and James Courtier-Dutton at 14/06/10 16:27 did gyre and gimble:
On 14 June 2010 15:17, Colin Guthrie gmane@colin.guthr.ie wrote:
I've made this change on my system and while previously my UI had no "Base Volume" displayed (because all my "h/w" (I include softvol in that) controls had their dB value >0.
Now that this change is live, I have a base volume present in my GUI (at around the 64% mark with the cubic scale we've already discussed). When I set my volume ot the base volume, the h/w controls are all set to 0dB which is exactly as expected.
I fail to see the point here? The base volume is clearly exposed to the as the recommended point on the scale at which no clipping occurs.
I really don't get where your complaint is.
Well, if you can define "Volume" in a way that lets you understand this then fine. For me, all these controls are not adjusting "Volume", they are adjusting "Gain", so why are they even called "Base Volume".
It's all about context. While "Gain" may be a more accurate terminology, the vast majority of users wont really understand this. The term "Volume" is much more readily understandable by the unwashed masses.
At the end of the day, "relative volume adjustments" and "gain" are the same thing but I guess people who understand and appreicate what 0dB means would think of gain as the net change of a system of controls from input to output, but think of volume as something absolute - e.g. a volume of 11 would sound the same regardless of source, where as a gain of +4dB would be meaningless in itself and be entirely dependant on the level of the source..... but trying to explain all this in a simple GUI you grannie can use is not really worth the effort IMHO.
Col
On Mon, Jun 14, 2010 at 04:27:32PM +0100, James Courtier-Dutton wrote:
Well, if you can define "Volume" in a way that lets you understand this then fine. For me, all these controls are not adjusting "Volume", they are adjusting "Gain", so why are they even called "Base Volume".
"Volume" has a specific meaning in the ALSA ABI.
2010/6/14 James Courtier-Dutton james.dutton@gmail.com
On 14 June 2010 15:17, Colin Guthrie gmane@colin.guthr.ie wrote:
I've made this change on my system and while previously my UI had no "Base Volume" displayed (because all my "h/w" (I include softvol in that) controls had their dB value >0.
Now that this change is live, I have a base volume present in my GUI (at around the 64% mark with the cubic scale we've already discussed). When I set my volume ot the base volume, the h/w controls are all set to 0dB which is exactly as expected.
I fail to see the point here? The base volume is clearly exposed to the as the recommended point on the scale at which no clipping occurs.
I really don't get where your complaint is.
alsamixer -D pulse does not show that sweet spot to the user
Well, if you can define "Volume" in a way that lets you understand this then fine. For me, all these controls are not adjusting "Volume", they are adjusting "Gain", so why are they even called "Base Volume".
If you play music using aplay or mplayer with modified front device , you should notice that the playback signal after passing the softvol plugin is already clipped when you set the softvol to 12dB (software gain is the cause of this clipping )
2010/6/14 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 14/06/10 13:36 did gyre and gimble:
2010/6/14 James Courtier-Dutton james.dutton@gmail.com
On 14 June 2010 11:22, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and James Courtier-Dutton at 14/06/10 09:56 did gyre and gimble:
If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
But it doesn't hide it. It's shown very clearly in the volume control GUIs as the Base Volume.
Do you really think that most users look at the sliders to find the 0dB point? Does gnome-alsa-mixer (the old one) expose this information? No. Does kmix? No. So the vast, vast majority of users do not know where
the
0dB point is unless they use alsamixer.... and even if the user is advanced enough to use alsamixer, then I'd still say a proportion of users are just looking at how far up the slider is rather than looking specifically for 0dB.
So I'd argue the exact opposite of your claim. That with the base
volume
clearly presented in the GUI, the h/w 0dB spot is much, much more obvious to the vast majority of users.
I really think this is a vast improvement over a complex balancing act of getting two different sliders setup to get distortion free audio!
Col
One has very different problems with capture than one does with
playback.
With capture it is important to identify which are analog controls (applied to the analog part of the circuit) and which are digital controls (applied to the digital part of the circuit) So, for capture one might wish to adjust the analog control so that the signal going into the ADC is a suitable level, but once the signal is digital, one should really not adjust it further, and just record what you have. If one was to combine these two capture controls in one PA control, it would just be wrong.
The AC97 recording from line-in problem seem not related to capture gain since you can set capture volume to 0dB
The HDA 's "PCM" softvol plugin is different from AC97 "PCM" Playback
volume
But you can change the softvol plugin to add gain to emulate the clipping
in
software side if PA developers did not have ac97 sound card ( clipping
occur
in hardware side )
/usr/share/alsa/cards/HDA-Intel.conf
HDA-Intel.pcm.front.0 { @args [ CARD ] @args.CARD { type string } type softvol slave.pcm { type hw card $CARD } control { name "PCM Playback Volume" card $CARD }
min_dB -46.5max_dB 12.0resolution 32}
I've made this change on my system and while previously my UI had no "Base Volume" displayed (because all my "h/w" (I include softvol in that) controls had their dB value >0.
as your card has no h/w gain, > 0dB , but the gain in softvol plugin is a software gain (i.e. in the red region in PA "s volume scale
how can base_volume display in gnome volume control (unamplified) ?
BTW , -46.5dB to 0dB of softvol plugin is software atten ( not h/w atten )
Now that this change is live, I have a base volume present in my GUI (at around the 64% mark with the cubic scale we've already discussed). When I set my volume ot the base volume, the h/w controls are all set to 0dB which is exactly as expected.
I fail to see the point here? The base volume is clearly exposed to the as the recommended point on the scale at which no clipping occurs.
I really don't get where your complaint is.
Col
'Twas brillig, and Raymond Yau at 22/06/10 03:31 did gyre and gimble:
2010/6/14 Colin Guthrie gmane@colin.guthr.ie
I've made this change on my system and while previously my UI had no "Base Volume" displayed (because all my "h/w" (I include softvol in that) controls had their dB value >0.
as your card has no h/w gain, > 0dB , but the gain in softvol plugin is a software gain (i.e. in the red region in PA "s volume scale
how can base_volume display in gnome volume control (unamplified) ?
BTW , -46.5dB to 0dB of softvol plugin is software atten ( not h/w atten )
As I said above, anything that comes from alsa is considered h/w amplification for the purposes of PA's volume scale. It's not practical to differentiate them.
Does any card actually configure softvol, by default, to provide any gain, > 0dB for outputs? If so, then this is IMO a bad idea.
Again, it's ultimately related to your range-checking bugbear. Users would want to know when both hardware and software amplification kicks in. In PA this is represented clearly by the 'Base Volume' marker for the case of "h/w amplification" and volumes >0dB/100% in the "software amplification".
Not all PA UIs allow this >0dB/100% slider: gnome-volume-control being one that does and something that as you know, I made an effort to standardise recently. I've not (yet) actually made much in the way of progress on this due to various time constraints, but the principle of what values to use is laid down.
FWIW, even within itself g-v-c is inconsistent. The full GUI allows up to this 150%/~+11dB mark (it works in percentages which is ugly - I'll be changing that), but the applet only goes up to 0dB which is rather annoying. I'll try and fix that if noone beats me to it.
Col
2010/6/22 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 22/06/10 03:31 did gyre and gimble:
2010/6/14 Colin Guthrie gmane@colin.guthr.ie
I've made this change on my system and while previously my UI had no "Base Volume" displayed (because all my "h/w" (I include softvol in that) controls had their dB value >0.
as your card has no h/w gain, > 0dB , but the gain in softvol plugin is
a
software gain (i.e. in the red region in PA "s volume scale
how can base_volume display in gnome volume control (unamplified) ?
BTW , -46.5dB to 0dB of softvol plugin is software atten ( not h/w atten
)
As I said above, anything that comes from alsa is considered h/w amplification for the purposes of PA's volume scale. It's not practical to differentiate them
Software gain is different from hardware gain.
Clipping due to software gain +12dB cannot compensated by -12dB by hardware atten
.
Does any card actually configure softvol, by default, to provide any gain, > 0dB for outputs? If so, then this is IMO a bad idea.
-51dB to 0dB is also software atten of softvol plugin
if PA did not want to differeniate hardware/software gain/atten Just set this softvol PCM to 0dB and use PA 's own software gain/atten or don't use front device for HDA
'Twas brillig, and Raymond Yau at 22/06/10 16:29 did gyre and gimble:
2010/6/22 Colin Guthrie gmane@colin.guthr.ie
As I said above, anything that comes from alsa is considered h/w amplification for the purposes of PA's volume scale. It's not practical to differentiate them
Software gain is different from hardware gain.
Really? Wow, thanks for that :p
Clipping due to software gain +12dB cannot compensated by -12dB by hardware atten
Another obvious statement, but not really anything to do with the discussion.
This only becomes a problem if the softvol plugin is configured to go
0dB. And if it is, then I've got to ask why....
You can configure all sorts of crazy and weird shit in alsa if you care to, but it's totally impractical for something higher in the stack to deal with all the nuances of the ultimate results of that configuration. As far as anything further up the stack is concerned, if it's represented in alsa, it's "hardware".
Just like softmodems, I don't care further up the stack whether or not the functionality is implemented in firmware or software, I just care that I have an interface to use a modem.
So, yes, of course you could configure softvol plugin to do nuts things in ALSA if you're that way inclined. I don't think anyone who is not trying to do weird things will do that, however, and I don't know of any particular h/w that is setup in a weird way by default either.
Does any card actually configure softvol, by default, to provide any gain, > 0dB for outputs? If so, then this is IMO a bad idea.
-51dB to 0dB is also software atten of softvol plugin
So that's not > 0dB then is it?
Col
2010/6/23 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 22/06/10 16:29 did gyre and gimble:
2010/6/22 Colin Guthrie gmane@colin.guthr.ie
As I said above, anything that comes from alsa is considered h/w amplification for the purposes of PA's volume scale. It's not practical to differentiate them
Software gain is different from hardware gain.
Really? Wow, thanks for that :p
Clipping due to software gain +12dB cannot compensated by -12dB by
hardware
atten
Another obvious statement, but not really anything to do with the discussion.
This only becomes a problem if the softvol plugin is configured to go
0dB. And if it is, then I've got to ask why....
You can configure all sorts of crazy and weird shit in alsa if you care to, but it's totally impractical for something higher in the stack to deal with all the nuances of the ultimate results of that configuration. As far as anything further up the stack is concerned, if it's represented in alsa, it's "hardware".
Just like softmodems, I don't care further up the stack whether or not the functionality is implemented in firmware or software, I just care that I have an interface to use a modem.
So, yes, of course you could configure softvol plugin to do nuts things in ALSA if you're that way inclined. I don't think anyone who is not trying to do weird things will do that, however, and I don't know of any particular h/w that is setup in a weird way by default either.
Does any card actually configure softvol, by default, to provide any gain, > 0dB for outputs? If so, then this is IMO a bad idea.
-51dB to 0dB is also software atten of softvol plugin
So that's not > 0dB then is it?
Col
As you have modified /usr/share/alsa/cards/HDA-Intel.conf
HDA-Intel.pcm.front.0 { @args [ CARD ] @args.CARD { type string } type softvol slave.pcm { type hw card $CARD } control { name "PCM Playback Volume" card $CARD }
you should notice that the front device has a softvol plugin with name "PCM Playback Volume"
why PA server still insist to open front device for capturing ?
http://thread.gmane.org/gmane.linux.alsa.devel/67912/focus=68248
As Takashi had already mention that
"I agree that the capture from "front" PCM isn't considered as valid. The "front", "rear", "center_lfe" definitions are rather for multi-channel playbacks. The capture on these channels aren't useful in most cases."
you can perform an experiement
pcm.test { type softvol slave.pcm "hw:0,0" control { name "PA Playback Volume" card 0 }
arecord -D test -f CD -d 10 -v test.wav
you will find "PA Playback Volume" in playback screen of alsamixer
I am not sure the softvol control created when PA open front device for playback and capture is used for playback or capture
BTW , PA still using "front" to open CTL device too
'Twas brillig, and Raymond Yau at 23/06/10 02:15 did gyre and gimble:
why PA server still insist to open front device for capturing ?
Couldn't tell you. Perhaps Lennart is unaware that it is considered invalid? I'll ask him.
http://thread.gmane.org/gmane.linux.alsa.devel/67912/focus=68248
As Takashi had already mention that
"I agree that the capture from "front" PCM isn't considered as valid. The "front", "rear", "center_lfe" definitions are rather for multi-channel playbacks. The capture on these channels aren't useful in most cases."
you can perform an experiement
pcm.test { type softvol slave.pcm "hw:0,0" control { name "PA Playback Volume" card 0 }
arecord -D test -f CD -d 10 -v test.wav
you will find "PA Playback Volume" in playback screen of alsamixer
I am not sure the softvol control created when PA open front device for playback and capture is used for playback or capture
BTW , PA still using "front" to open CTL device too
You'll have to ask Lennart directly about that bit.
I can't speak for him with regards to the full setup of the mixer path probing stuff, so perhaps "front" should be edited out of this for paths. It would likely be a fairly trivial change to configuration files rather than any code changes.
Col
2010/6/23 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 23/06/10 02:15 did gyre and gimble:
why PA server still insist to open front device for capturing ?
Couldn't tell you. Perhaps Lennart is unaware that it is considered invalid? I'll ask him.
http://thread.gmane.org/gmane.linux.alsa.devel/67912/focus=68248
As Takashi had already mention that
"I agree that the capture from "front" PCM isn't considered as valid. The "front", "rear", "center_lfe" definitions are rather for
multi-channel
playbacks. The capture on these channels aren't useful in most cases."
you can perform an experiement
pcm.test { type softvol slave.pcm "hw:0,0" control { name "PA Playback Volume" card 0 }
arecord -D test -f CD -d 10 -v test.wav
you will find "PA Playback Volume" in playback screen of alsamixer
I am not sure the softvol control created when PA open front device for playback and capture is used for playback or capture
BTW , PA still using "front" to open CTL device too
You'll have to ask Lennart directly about that bit.
arecord -Dfront:0 -v -f cd | aplay -Dfront:0 -v -f cd
the softvol control was seem to used by arecord and aplay concurrently
Using front device for capture 1) HDA, the problem is softvol plugin, 2) emu10k1 , the problem is the hook controls in front playback device which change the route of volume of the DSP hardware mixer 3)
I can't speak for him with regards to the full setup of the mixer path probing stuff, so perhaps "front" should be edited out of this for paths. It would likely be a fairly trivial change to configuration files rather than any code changes.
Col
Well , He had already hardcoded to use "hw:card_number" in dbverify.c , it is only PA server still try to open mixer device "front"
The tooltip of gnome volume control in Fedora 13 clearly indiacte that 100% is 0dB for intel8x0 which use ac97 codec when you put the cursor on top of the speaker icon at the system bar
https://bugzilla.gnome.org/show_bug.cgi?id=618551
according to gnome-media-developer Bastien Nocera
In any case, we only display what PulseAudio tells us, so you should poke the PulseAudio devs about this.
This is the code in question: gdouble gvc_mixer_stream_get_decibel (GvcMixerStream *stream) { g_return_val_if_fail (GVC_IS_MIXER_STREAM (stream), 0);
return pa_sw_volume_to_dB( (pa_volume_t) gvc_channel_map_get_volume(stream->priv->channel_map)[VOLUME]); }
if you don't have any ac97 sound card , you can user virtualbox which has an emulated intel8x0 sound card
'Twas brillig, and Raymond Yau at 28/06/10 02:47 did gyre and gimble:
2010/6/23 Colin Guthrie gmane@colin.guthr.ie
I can't speak for him with regards to the full setup of the mixer path probing stuff, so perhaps "front" should be edited out of this for paths. It would likely be a fairly trivial change to configuration files rather than any code changes.
Well , He had already hardcoded to use "hw:card_number" in dbverify.c , it is only PA server still try to open mixer device "front"
Yeah dbverify is a very simple tool that doesn't really warrant an advanced interface. There may be other reasons to use hw: directly too.
The tooltip of gnome volume control in Fedora 13 clearly indiacte that 100% is 0dB for intel8x0 which use ac97 codec when you put the cursor on top of the speaker icon at the system bar
https://bugzilla.gnome.org/show_bug.cgi?id=618551
according to gnome-media-developer Bastien Nocera
In any case, we only display what PulseAudio tells us, so you should poke the PulseAudio devs about this.
This is the code in question: gdouble gvc_mixer_stream_get_decibel (GvcMixerStream *stream) { g_return_val_if_fail (GVC_IS_MIXER_STREAM (stream), 0);
return pa_sw_volume_to_dB( (pa_volume_t)gvc_channel_map_get_volume(stream->priv->channel_map)[VOLUME]); }
if you don't have any ac97 sound card , you can user virtualbox which has an emulated intel8x0 sound card
Dude, we've talked about this already. The PA server applies no software amplification and has set the controls provided by ALSA to their maximum, which we call 0dB.
This approach allows us to fit in with a slider system that has 0dB at it's top end and we can also show the ALSA 0dB point as the "Base Volume" in our UIs.
Now you could argue (which you obviously are) that the dB of the underlying card should still be exposed in the purest sense, but that does make for more complicated calculations and confusing repercussions elsewhere, including the mapping from percentage to dB not being consistent (e.g. sometimes 100% is 0dB, sometimes it's 12dB etc.).
You could also argue that any controls that go >0dB should just be ignored by PA - i.e. we never control the mixers in a way that would go over 0dB unless we're going above our 100%. That may be a more valid approach, but it needs a standard way to represent volumes >100% which would then fall into the zone of influence of your other current bugbear: the range checking thing in alsa-lib/alsamixer. Ultimately this boils down to the fact that the 0dB point in some alsa mixers is located at a random percentage < 100%. This is fundamentally the problem we are trying to combat and make it clear to the user where that point is.
So as I've said before, the current approach is IMO the best way to fit in with the semantics currently available. If you change those semantics and provide mechanisms to represent a tri-range (min, 100%/0dB, max) then we could probably adjust to fit in with those semantics. But none currently exist. So we'll stick with how it's done now for the time being.
Col
2010/6/28 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 28/06/10 02:47 did gyre and gimble:
The tooltip of gnome volume control in Fedora 13 clearly indiacte that
100%
is 0dB for intel8x0 which use ac97 codec when you put the cursor on top
of
the speaker icon at the system bar
https://bugzilla.gnome.org/show_bug.cgi?id=618551
according to gnome-media-developer Bastien Nocera
In any case, we only display what PulseAudio tells us, so you should poke
the
PulseAudio devs about this.
This is the code in question: gdouble gvc_mixer_stream_get_decibel (GvcMixerStream *stream) { g_return_val_if_fail (GVC_IS_MIXER_STREAM (stream), 0);
return pa_sw_volume_to_dB( (pa_volume_t)gvc_channel_map_get_volume(stream->priv->channel_map)[VOLUME]); }
if you don't have any ac97 sound card , you can user virtualbox which has
an
emulated intel8x0 sound card
Dude, we've talked about this already. The PA server applies no software amplification and has set the controls provided by ALSA to their maximum, which we call 0dB.
This is completely wrong when you rename ALSA driver's max_dB to PA 's 0dB
Most applications does not provide any software gain/atten too, when the ALSA drivers 's volume control is at Max dB (e.g. +12dB for ac97 PCM ) , it is still 12dB as long as you changed the hardware volume control to 12dB, it can be 0dB only if PA can provide -12dB (software atten)
the dB value of playback/capture in gnome-volume-control and "alsamixer -c0" should be the same for any sound card.
a simple test case is using aplay which did not provide any software gain/atten
For the ac97 sound card with PCM -34.5dB to +12 dB ( assume that you have already set the ac97 "Master" to 0dB )
1) aplay -Dhw:0,0 any.wav with "alsamixer -c0 " "Master" at 0.dB and "PCM" at 12.dB
2) aplay -Dpulse any.wav with gnome volume control at max(0dB) 100%
In both case, "alsamixer -c0" tell you that it is +12dB in playback gain but gnome-volume-control tell you that it is 0dB gain
if you use decibel meter, voltmeter or oscilloscope to measure the output signal those meters should tell you those two signals are at same level
PA should not rename the dB value on volume scale just because the computation of the dB value is complicated since user cannot rely on this shifted dB scale to perform distortion free line level playback/recording (this require to set both playback and capture volume control at 0dB)
In simple word, PA is actually provide a wrong dB value to gnome volume control for those driver which the max_dB is > 0
PA 's renamin max_dB to 0dB is not limited to those drivers with max_dB > 0
it also affect those driver with max_dB < 0
http://thread.gmane.org/gmane.linux.alsa.devel/73114/focus=73125
Original range (127): -63.5 .. 0 dB Limited range (100): -63.5 .. -13.5 dB
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=30ad5ed04017f7e77...
http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=7bc5cd78454bee5990d29a0b...
PA cannot rename -13.5dB as 0dB after the driver limited the max_dB to -13.5dB by reducing the number of steps of the control
No. -inf dB is -inf dB. If the card does not go down to -inf dB, PA will
extend the range in >> software. If a card only goes down to -12dB minimum the range -12dB -> -infdB will be >> done in software. Lennart explained this very clearly to you already.
It is unlikely for PA just provide software atten for this range (-inf dB to min dB) since PA volume control has 65536 steps
As most sound cards only provide 32 to 256 steps by hardware (e.g. DAC/ADC/codec)
The value returned by get_playback_dB() may different from set_playback_dB() when the driver cannot set the dB value between two hardware steps (e.g. ac97 codec 1.5dB per step , so you cannot set playback volume to -0.1dB by using hw volume control alone, this is still true even when some HDA codec support 0.25 dB per step )
This mean that if PA want to set playback volume to -0.1dB, it have to set the hardware control to 0dB and peform software atten -0.1dB or set the hardware control to -1.5dB and perform software gain +1.4dB
Can you explain whether PA perform software atten in the above case ?
PA seem did not care about the difference of variable "f" before and after calling snd_mixer_selem_set_playback_dB() and snd_mixer_selem_get_playback_dB() to perform necessary software gain/atten (difference of f )
static int element_set_volume(pa_alsa_element *e, snd_mixer_t *m, const pa_channel_map *cm, pa_cvolume *v) {
if (e->has_dB) { long value = to_alsa_dB(f);
if (e->direction == PA_ALSA_DIRECTION_OUTPUT) { /* If we call set_play_volume() without checking first * if the channel is available, ALSA behaves ver * strangely and doesn't fail the call */ if (snd_mixer_selem_has_playback_channel(me, c)) { if ((r = snd_mixer_selem_set_playback_dB(me, c, value, +1)) >= 0) r = snd_mixer_selem_get_playback_dB(me, c, &value); } else r = -1; } else { if (snd_mixer_selem_has_capture_channel(me, c)) { if ((r = snd_mixer_selem_set_capture_dB(me, c, value, +1)) >= 0) r = snd_mixer_selem_get_capture_dB(me, c, &value); } else r = -1; }
if (r < 0) continue;
#ifdef HAVE_VALGRIND_MEMCHECK_H VALGRIND_MAKE_MEM_DEFINED(&value, sizeof(value)); #endif
f = from_alsa_dB(value);
} else {
On Mon, 14.06.10 11:46, James Courtier-Dutton (james.dutton@gmail.com) wrote:
One has very different problems with capture than one does with playback. With capture it is important to identify which are analog controls (applied to the analog part of the circuit) and which are digital controls (applied to the digital part of the circuit) So, for capture one might wish to adjust the analog control so that the signal going into the ADC is a suitable level, but once the signal is digital, one should really not adjust it further, and just record what you have. If one was to combine these two capture controls in one PA control, it would just be wrong.
Well, we apply volumes going from the "outer end" to the "inner end" of the pipeline. That should have the affect that the biggest part is done on the analog elements (i.e. "outer") and only minimal attenuation on the digital elements (i.e. "inner").
In short: this should be covered nicely by PA already, at least if the ALSA mixer used somewhat standard names for things.
I think there is some indication with the name of the control. It sometimes has "Analog" or "Digital" attached to it. I think this would be better if alsa reported the "Analog" or "Digital" as meta data, like the dB Scales. PA could then make more informed decisions for capture. I.e. only display the "Analog" controls, and hide the digital ones, setting them to 0dB.
I think it is advisable to to attenuation in hw if possible, simply to minimize CPU load. Hence we try to do the biggest volume adjustment in analog hw, and everything we cannot apply there we do in digital hw, and finally everything else in sw.
Lennart
On Mon, 14.06.10 11:22, Colin Guthrie (gmane@colin.guthr.ie) wrote:
'Twas brillig, and James Courtier-Dutton at 14/06/10 09:56 did gyre and gimble:
On 14 June 2010 09:33, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM" volume above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
What do you mean. If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
But it doesn't hide it. It's shown very clearly in the volume control GUIs as the Base Volume.
Let me also stress that "dB" is not at all understandable to most people. It is a very technical unit, and showing 0dB in the UI just like that won't be very helpful for most people.
That's why we thought about this, and are recommending a color coded slider to be exposed in the UI which encodes the range information in a sane way that is intuitively understandable by users. In green, in yellow and in red. (meaning hw attenuated, hw amplified, sw amplified ranges)
http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders
Lennart
2010/6/15 Lennart Poettering mznyfn@0pointer.de
On Mon, 14.06.10 11:22, Colin Guthrie (gmane@colin.guthr.ie) wrote:
'Twas brillig, and James Courtier-Dutton at 14/06/10 09:56 did gyre and gimble:
On 14 June 2010 09:33, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record
the
output from hw:0,0 and you will see clipping occur when you set "PCM"
volume
above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
What do you mean. If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot". I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
But it doesn't hide it. It's shown very clearly in the volume control GUIs as the Base Volume.
Let me also stress that "dB" is not at all understandable to most people. It is a very technical unit, and showing 0dB in the UI just like that won't be very helpful for most people.
That's why we thought about this, and are recommending a color coded slider to be exposed in the UI which encodes the range information in a sane way that is intuitively understandable by users. In green, in yellow and in red. (meaning hw attenuated, hw amplified, sw amplified ranges)
http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders
Lennart
Clipping may occur at recording if there is gain above hardware 0dB point , the region should be coloured as red ,
What is the meaning of the yellow region ?
For HDA base volume seem to be at the same point as the norm volume since max_db of playback is 0dB
+12dB(400%) is even larger than the software gain 150% of PA
'Twas brillig, and Raymond Yau at 15/06/10 00:43 did gyre and gimble:
+12dB(400%) is even larger than the software gain 150% of PA
Software gain of PA 150% = ~+11dB, so not as different as you imply.
I've explained the cubic mapping already, so please don't use arbitrary, differently calculated percentages when comparing things. It's like comparing apples to oranges.
Col
On Mon, 14.06.10 09:56, James Courtier-Dutton (james.dutton@gmail.com) wrote:
On 14 June 2010 09:33, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and Raymond Yau at 14/06/10 01:25 did gyre and gimble:
if your sound card have ac97 codec ., you can use audacity to record the output from hw:0,0 and you will see clipping occur when you set "PCM" volume above 0dB
So the standard response is "don't do that then" :)
That's why the base volume is shown to the user via GUIs so that they can gauge the best point on the slider to use. Currently there is no indication with alsa sliders at which point the 0dB "sweet spot" lies.
What do you mean. If you use "alsamixer", dB values are shown so it is easy to find the 0dB "sweet spot".
Whether dB is shown or not has nothing to do with PA. Some UIs show it, others don't. And most UIs do show the "base volume" too, which refers to the ALSA 0dB "comfort" point. There is nothing lost here. We just simplified things a littl and made the volume range infinite, as well as we unified what things look like on various hardware.
I think it is pulse audio that hides this information when it combines two alsa mixer controls into one pulseaudio control.
No, we don't. The final "base volume" will be put where all sliders that are merged are at 0dB.
Lennart
2010/6/7 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 06/06/10 01:12 did gyre and gimble:
2010/5/28 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Colin Guthrie at 27/05/10 15:43 did gyre and gimble:
PA should play nice with the softvol plugin so I don't think this is
the
bit that is at fault.
I strongly suspect that the reason has already been correctly
identified
a while ago, which is that this card considers -48dB silent where as PA assumes this level is -200dB. I believe it was Raymond who pointed out the -48dB level in the HDA spec before on this list.
if floating point 0.0 is -inf dB , and 1.0 is 0dB ,
0.5 is -6dB , 0.25 is -12 dB , 0.125 is -24dB and 0.0625 is -48dB
This is just a pure mapping from dB->linear, but as this linear mapping is generally not "natural" there are several different approaches to presenting this to users. In PA, a cubic mapping is used on top of this basic conversion, to map to the percentage scale (0.0 to 1.0 if you like).
So I'm not sure what point you're making by providing these numbers. Can you explain?
how can PA master volume control at 10~15% equivalent to HDA 's -48dB ?
Not sure what you mean here, but I suspect it's the cubic mapping that is confusing you.
FWIW, I've got the same/similar h/w with a cutoff at 14% in PA as you
have.
According to your email , you mention than your hardware has a cutoff at 14% in PA
the mixer application programmer can select any kind of scaling in the slider
do you mean 14% in pavucontrol or Master volume control of "pulse" device ?
but pavucontrol did not provide any dB value at any point
'Twas brillig, and Raymond Yau at 08/06/10 05:01 did gyre and gimble:
According to your email , you mention than your hardware has a cutoff at 14% in PA
It's actually closer to about 16%... but in that area yes.
the mixer application programmer can select any kind of scaling in the slider
Indeed, but pulseaudio exposes a pa_volume_t which is basically a linear scale. This upper bound is exposed via a constant: PA_VOLUME_MAX
pulse/volume.h:113:#define PA_VOLUME_MAX ((pa_volume_t) UINT32_MAX-1)
And the "100%" aka 0dB point is represented by another constant, PA_VOLUME_NORM:
pulse/volume.h:107:#define PA_VOLUME_NORM ((pa_volume_t) 0x10000U)
The scale between 0 and PA_VOLUME_NORM is linear via pa_volume_t but this is mapped via the cubic mapping internally when controling the volume of the alsa device.
So volume control GUIs and the ALSA plugin use this scale in a linear fashon to represent the rand 0% (pa_volume_t = 0) to 100% (pa_volume_t = PA_VOLUME_NORM).
do you mean 14% in pavucontrol or Master volume control of "pulse" device ?
Both. They both use the range 0 ... PA_VOLUME_NORM to represent 0% - 100% and thus they correspond with each other fine[1]
but pavucontrol did not provide any dB value at any point
It doesn't display the dB value, but perhaps it should? It's more of a developer tool anyway (tho' used by a lot of users until desktop provided tools catch up) so exposing dB here would make sense IMO. I'll cook up a patch.
Col
1. Note that this may change at some point in the future as we define how much to show the user as an "overdrive" of volume. As you may know, gnome-volume-control allows a setting up to 150%, but this isn't refelected in the alsa plugin. Ultimately we decided to define a new constant "PA_VOLUME_OVERDRIVE" (or similar, I can't remember the exact name) and set this to be +11dB (via the current cubic mapping function). This approximates to the 150% offered in g-v-c.
2010/5/27 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Clemens Ladisch at 27/05/10 14:48 did gyre and gimble:
Colin Guthrie wrote:
state.Intel { control.1 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -4650 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value.0 30 value.1 30 }
This is the hardware volume control.
control.11 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 253 value.1 253 }This is the emulated software volume control that is created by the softvol plugin. This control gets recreated by "alsactl restore" even when the plugin is not running.
Might it be possible that PA is trying to use this, but that it doesn't have any effect because PA is using PCM device hw:0? (Try unloading snd-hda-intel and then deleting that entry from /etc/asound.state.)
PA should play nice with the softvol plugin so I don't think this is the bit that is at fault.
For AC97 codec
PCM -34.5dB to +12 dB Master -46.5dB to 0dB
The total dB range is -81dB to +12dB
For HDA
No idea how to know the master volume control is a virtual master volume control
The softvol plugin -51dB to -0dB is software atten of the input digital signal before pass to the HDA sound card
PA seem has its own software atten/gain and mixing of the digital signal from the PA clients
I strongly suspect that the reason has already been correctly identified a while ago, which is that this card considers -48dB silent where as PA assumes this level is -200dB. I believe it was Raymond who pointed out the -48dB level in the HDA spec before on this list.
Different HDA codecs have different dB range according to the HDA spec
I'm not sure of the internals, but things do indeed go silent when the volume reaches the magic -48dB mark (which is around the 14% mark with the current cubic mapping).
I suspect that if I were to define infinity to be 48.0 in PA, everything would work nicely.
I have doubt since I can still hear sound when using ac97 codec of my au8830 below -48dB and using baudline (require OSS emulation) also indicate that there is signal recorded by using loopback of ac97 codec
What I think is then ultimately needed is a way to ensure that everyone sings from the same hymn sheet regarding the real world value of -inf dB.
I was hoping Lennart would have commented on this thread by now, so I'll try and prod him to get some proper input as I'm very much flailing around wildly in the dark!
Col
2010/5/27 Clemens Ladisch clemens@ladisch.de
Colin Guthrie wrote:
state.Intel { control.1 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -4650 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value.0 30 value.1 30 }
This is the hardware volume control.
control.11 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 253 value.1 253 }This is the emulated software volume control that is created by the softvol plugin. This control gets recreated by "alsactl restore" even when the plugin is not running.
Might it be possible that PA is trying to use this, but that it doesn't have any effect because PA is using PCM device hw:0? (Try unloading snd-hda-intel and then deleting that entry from /etc/asound.state.)
Regards, Clemens
if I make a customised device "test" with softvol plugin with name "P Playback Volume" in .asounrd
aplay -D test.wav
alsamixer -c0 show the "P" control and volume change as expected
Then change the name from "P Playback Volume" to "Q Playack Volume" and play audio through device "test" again
alsamixer -c0 show both "P" and "Q" controls
"P" control can go up/down with no effect of course
but "Q" stayed at 100%
Is this a bug ?
2010/4/3 Nicolo' Chieffo nicolo.chieffo@gmail.com
Hello, I have a laptop with an intel hda audio chipset (STAC92xx)
My problem is that when I put pulseaudio volume to 14% (or less) I can't hear any audio coming from speakers or headphones: in fact the alsamixer volume is set to 0%
I already filed a bug to pulseaudio [1] in which the developers say that this is a common problem which is usually caused by the ALSA audio driver which reports a wrong decibel value.
please provide the output of "amixer -D pulse" when you set the volume control of alsamixer to (-3dB , -6dB , -12 dB , -24 dB and -48dB ) using "alsamixer -c 0"
I've already attached my alsa-info.log in my first post.
* alsamixer -48 dB (0%) Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 10151 [15%] [on] Front Right: Playback 10151 [15%] [on]
* alsamixer -24 dB (50%) Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 25693 [39%] [on] Front Right: Playback 25693 [39%] [on]
* alsamixer -12 dB (75%): Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 40409 [62%] [on] Front Right: Playback 40409 [62%] [on]
* alsamixer -6 dB (88%): Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 50872 [78%] [on] Front Right: Playback 50872 [78%] [on]
* alsamixer -3 dB (94%): Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 57079 [87%] [on] Front Right: Playback 57079 [87%] [on]
* alsamixer 0 dB (100%): Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 64044 [98%] [on] Front Right: Playback 64044 [98%] [on]
2010/4/6 Nicolo' Chieffo nicolo.chieffo@gmail.com
I've already attached my alsa-info.log in my first post.
- alsamixer -3 dB (94%):
Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 57079 [87%] [on] Front Right: Playback 57079 [87%] [on]
- alsamixer 0 dB (100%):
Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 64044 [98%] [on] Front Right: Playback 64044 [98%] [on]
you should notice that 0dB of Pulseaudio volume control is not at the maximum dB i.e. ( floating point 1.0 is not at 100% any more , seem that floating point 0 (-inf dB) is also not at 0% point too )
http://thread.gmane.org/gmane.linux.alsa.devel/70545/focus=70585
As mentioned for the PA case I decided to shift 0dB to max
amplification in any case, which I think is a workable way to avoid this problem.
how about "dbmeasure pulse" and "dbmeasure hw:0,0" ?
On Wed, Apr 7, 2010 at 2:34 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
how about "dbmeasure pulse" and "dbmeasure hw:0,0" ?
I don't have a line out and in plug, only headphones and mic. Does it work? At which volume should I put the mic?
This is what I'm doing: - got a jack-jack audio cable - connected the headphone to the mic - open alsamixer and put everything to 0 dB - verified that the pass-throw works by using the sound recorder
./dbmeasure plughw:0 dbmeasure_hw.log
exits with this error:
Iteration 1, level is 0 (-inf dB). Volume level measured (0) was too high or too low. Please adjust mixer so that initial level is between 0.8 and 0.97. Test run canceled.
I've also tried to put the mic level at 100% (22.50 dB) but the output is the same.
2010/4/7 Nicolo' Chieffo nicolo.chieffo@gmail.com
This is what I'm doing:
- got a jack-jack audio cable
- connected the headphone to the mic
- open alsamixer and put everything to 0 dB
- verified that the pass-throw works by using the sound recorder
./dbmeasure plughw:0 dbmeasure_hw.log
exits with this error:
Have you ask the author of "dbmeasure" ?
Iteration 1, level is 0 (-inf dB). Volume level measured (0) was too high or too low. Please adjust mixer so that initial level is between 0.8 and 0.97. Test run canceled.
I've also tried to put the mic level at 100% (22.50 dB) but the output is the same.
your card seem to support 16/20/24bits
if you right shift your 16/24 bits digital audio by 16/24 bits , the digital data are always zero so any software atten on a 16/24bits sound card is still a finite negative number dB instead of -inf dB
that 's why the professional user prefer 32bits sound card
2010/4/6 Nicolo' Chieffo nicolo.chieffo@gmail.com
I've already attached my alsa-info.log in my first post.
- alsamixer 0 dB (100%):
Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 64044 [98%] [on] Front Right: Playback 64044 [98%] [on]
Most users only care about 0dB point since any software gain is the cause of clipping (distortion) when the volume control provide software gain
http://en.wikipedia.org/wiki/Clipping_%28audio%29
In digital signal processinghttp://en.wikipedia.org/wiki/Digital_signal_processing, clipping occurs when the signal is restricted by the range of a chosen representation. For example in a system using 16-bit signedhttp://en.wikipedia.org/wiki/Signed-digit_representationintegers, 32767 is the largest positive value that can be represented, and if during processing the amplitude of the signal is doubled, samplehttp://en.wikipedia.org/wiki/Sample_%28signal%29values of 32000 should become 64000, but instead they are truncated to the maximum, 32767.
I'm sorry but I found out that I gave you wrong values of "amixer -D pulse": I just discovered that when I lower the alsa master volume, in some occasions the PCM volume goes to 99%, so now I will put it to 100% and check the pulse volume again.
0 dB = 65536 [100%] -3 dB = 57520 [88%] -6 dB = 52057 [79%] -12 dB = 41034 [63%] -24 dB = 26090 [40%] -48 dB = 10151 [15%]
So again, the only problem is that -48 dB IS mute, but it's not declared as mute. This is the real issue.
2010/4/8 Nicolo' Chieffo nicolo.chieffo@gmail.com
I'm sorry but I found out that I gave you wrong values of "amixer -D pulse": I just discovered that when I lower the alsa master volume, in some occasions the PCM volume goes to 99%, so now I will put it to 100% and check the pulse volume again.
0 dB = 65536 [100%] -3 dB = 57520 [88%] -6 dB = 52057 [79%] -12 dB = 41034 [63%] -24 dB = 26090 [40%] -48 dB = 10151 [15%]
So again, the only problem is that -48 dB IS mute, but it's not declared as mute. This is the real issue.
Refer to HD audio specification
7.3.4.10 Amplifier Capabilities
Mute Capable (1 bit) reports if the respective amplifier is capable of muting. Muting implies a –infinity gain (no sound passes), but the actual performance is determined by the hardware.
http://thread.gmane.org/gmane.linux.alsa.devel/39262/focus=16100
Clemens Ladisch (developer) 2004-11-09 09:26
The AD1981B's datasheet says that the maximum attenuation is 46.5 dB
(which
conforms to the AC'97 specification). To mute, use Mute.
refer to your codec datasheet , the volume knob widget also affect the volume if it is configured in direct mode
• DIRECT MODE • In Direct mode, the Volume Knob widget directly controls the volume of all of the DACs in the part. The volume in the Volume Knob widget acts as the master volume and limits the maximum volume for each of the DAC amplifiers. The amp gain for each of the DACs can also be adjusted using the DAC amplifiers. However, the actual gain for an individual DAC will be the sum of the Volume Knob volume and the DAC amplifier volume. For example, if the DAC amplifier gain is set to 0x7F (0dB) and the Volume Knob volume is set to 0x3F (-48dB) the resulting gain would be -48dB. If the combination of gains is less than -95.25dB (the equivalent to a value of 0x0 for the DAC or Volume Knob volume settings) then the actual gain will be -95.25dB. For example, if the Volume Knob is set to 0x3F (-48dB) and the DAC amplifier volume is set to 0x1F (-72dB) then the DAC volume will be set to -95.25dB.
On Fri, Apr 9, 2010 at 1:11 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
Mute Capable (1 bit) reports if the respective amplifier is capable of muting. Muting implies a –infinity gain (no sound passes), but the actual performance is determined by the hardware.
http://thread.gmane.org/gmane.linux.alsa.devel/39262/focus=16100
I think you missed the point, I'll explain again. I'm not complaining that at 0% the audio is not mute, as the bug you linked.
Clemens Ladisch (developer) 2004-11-09 09:26 The AD1981B's datasheet says that the maximum attenuation is 46.5 dB (which conforms to the AC'97 specification). To mute, use Mute.
In fact my problem is that at 0% I get mute, but I shouldn't (as reported by that developer), since the max attenuation is not -inf, but -48 dB. So if you prefer, you could see this issue from a different point of view: at -48 dB the audio should be still audible, but it's not.
so you have to decide where the issue resides (but definitely not in pulseaudio) a) it is ok that the audio is mute at 0% (in this case you have to declare -inf dB) b) the audio level is really -48 dB (in this case the volume shouldn't be cut off completely, but simply quite low) Which one do you prefer?
2010/4/9 Nicolo' Chieffo nicolo.chieffo@gmail.com
On Fri, Apr 9, 2010 at 1:11 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
Mute Capable (1 bit) reports if the respective amplifier is capable of muting. Muting implies a –infinity gain (no sound passes), but the actual performance is determined by the hardware.
http://thread.gmane.org/gmane.linux.alsa.devel/39262/focus=16100
I think you missed the point, I'll explain again. I'm not complaining that at 0% the audio is not mute, as the bug you linked.
Clemens Ladisch (developer) 2004-11-09 09:26 The AD1981B's datasheet says that the maximum attenuation is 46.5 dB (which conforms to the AC'97 specification). To mute, use Mute.
In fact my problem is that at 0% I get mute, but I shouldn't (as reported by that developer), since the max attenuation is not -inf, but -48 dB. So if you prefer, you could see this issue from a different point of view: at -48 dB the audio should be still audible, but it's not.
so you have to decide where the issue resides (but definitely not in pulseaudio) a) it is ok that the audio is mute at 0% (in this case you have to declare -inf dB) b) the audio level is really -48 dB (in this case the volume shouldn't be cut off completely, but simply quite low) Which one do you prefer?
All the alsa drvier are using information in the codec datasheet to implement the dB scale
All the AC97 codec datasheet, DAC datahseet and HDA codec specifcation and datasheet are regarded the mute switch as -inf dB , the minimum dB are a finite negative number because the codec , DAC and HDA codec have finite bits of resolution when convert digital signal to analog signal
For your case if you change DAC amplifier volume control to -inf dB , how can you calculate the sum of Volume knob widget and DAC ampilifer volume control since the datasheet explicitly mention that the max atten is 95.25dB
may be pulseaudio did not add the volume knob widget in the calculation
I don't know how PA calculate the softvol plugin "PCM volume control" since you mention that PA seem not maintain "PCM volume control" at 0dB
2010/4/9 Nicolo' Chieffo nicolo.chieffo@gmail.com
On Fri, Apr 9, 2010 at 1:11 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
Mute Capable (1 bit) reports if the respective amplifier is capable of muting. Muting implies a –infinity gain (no sound passes), but the actual performance is determined by the hardware.
http://thread.gmane.org/gmane.linux.alsa.devel/39262/focus=16100
I think you missed the point, I'll explain again. I'm not complaining that at 0% the audio is not mute, as the bug you linked.
Clemens Ladisch (developer) 2004-11-09 09:26 The AD1981B's datasheet says that the maximum attenuation is 46.5 dB (which conforms to the AC'97 specification). To mute, use Mute.
In fact my problem is that at 0% I get mute, but I shouldn't (as reported by that developer), since the max attenuation is not -inf, but -48 dB. So if you prefer, you could see this issue from a different point of view: at -48 dB the audio should be still audible, but it's not.
so you have to decide where the issue resides (but definitely not in pulseaudio) a) it is ok that the audio is mute at 0% (in this case you have to declare -inf dB) b) the audio level is really -48 dB (in this case the volume shouldn't be cut off completely, but simply quite low) Which one do you prefer?
But you still not provide the result of dbmeasure of "pulse" , "hw:0" and "plug:front"
As I've already told you, I'm not able to run dbmeasure because it says it can't detect any audio. I will investigate...
2010/4/9 Nicolo' Chieffo nicolo.chieffo@gmail.com
As I've already told you, I'm not able to run dbmeasure because it says it can't detect any audio. I will investigate...
I cannot run dbmeasure on my au8830 or HDA sound card too.
you have to ask the author of dbmeasure.c
First glance at the source code , it seem the program expect the driver support exactly one second buffer but neither au8830 or HDA driver can offer a buffer size of exactly one second
May be just only work on his USB audio only
2010/4/9 Nicolo' Chieffo nicolo.chieffo@gmail.com
On Fri, Apr 9, 2010 at 1:11 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
Mute Capable (1 bit) reports if the respective amplifier is capable of muting. Muting implies a –infinity gain (no sound passes), but the actual performance is determined by the hardware.
http://thread.gmane.org/gmane.linux.alsa.devel/39262/focus=16100
I think you missed the point, I'll explain again. I'm not complaining that at 0% the audio is not mute, as the bug you linked.
Clemens Ladisch (developer) 2004-11-09 09:26 The AD1981B's datasheet says that the maximum attenuation is 46.5 dB (which conforms to the AC'97 specification). To mute, use Mute.
In fact my problem is that at 0% I get mute, but I shouldn't (as reported by that developer), since the max attenuation is not -inf, but -48 dB. So if you prefer, you could see this issue from a different point of view: at -48 dB the audio should be still audible, but it's not.
so you have to decide where the issue resides (but definitely not in pulseaudio) a) it is ok that the audio is mute at 0% (in this case you have to declare -inf dB) b) the audio level is really -48 dB (in this case the volume shouldn't be cut off completely, but simply quite low) Which one do you prefer?
The DR of 16bit audio is 96dB
http://en.wikipedia.org/wiki/Dynamic_range
The 16-bit compact disc http://en.wikipedia.org/wiki/Compact_disc has a theoretical dynamic range of about 96 dB[7]http://en.wikipedia.org/wiki/Dynamic_range#cite_note-Fries2005-6(or about 98 dB for sinusoidal signals, per the formula [6] http://en.wikipedia.org/wiki/Dynamic_range#cite_note-seeber-5). Digital audio with 20-bit digitization is theoretically capable of 120 dB dynamic range; similarly, 24-bit digital audio calculates to 144 dB dynamic range.[4]http://en.wikipedia.org/wiki/Dynamic_range#cite_note-HuberRunstein2005-3All digital audio recording and playback chains include input and output converters and associated analog circuitry, significantly limiting practical dynamic range. Observed 16-bit digital audio dynamic range is about 90 dB
The SNR of your codec is 95dB SNR
This mean that PA not using all the sum of the volume of the amplifer and volume knob widget to calculate the dB value of your codec
You are saying that the range for my card is 96 dB, do you mean that the audio specs are wrong? I mean, at 0 the volume is not audible, so I'm wondering why the -inf "switch register" is not activated (inside the chip)...
DMBEASURE
There's still no way to run the measurement with "pulse" because of the previous error:Iteration 1, level is 0 (-inf dB). Volume level measured (0) was too high or too low. Please adjust mixer so that initial level is between 0.8 and 0.97. Test run canceled. Are you sure that the test has sense using the pulse device?
"./dbmeasure plug:front plug_front.csv" works, but seems to never end: Iteration 3297, level is 0.0414072 (-27.6585 dB). Iteration 3298, level is 0.0414074 (-27.6584 dB). Iteration 3299, level is 0.0414064 (-27.6587 dB). Iteration 3300, level is 0.041406 (-27.6587 dB). .....
"./dbmeasure hw:0 hw.csv" fails with this message: "Cannot set sample format: Invalid argument"
2010/4/10 Nicolo' Chieffo nicolo.chieffo@gmail.com
DMBEASURE
There's still no way to run the measurement with "pulse" because of the previous error:Iteration 1, level is 0 (-inf dB). Volume level measured (0) was too high or too low. Please adjust mixer so that initial level is between 0.8 and 0.97. Test run canceled. Are you sure that the test has sense using the pulse device?
"./dbmeasure plug:front plug_front.csv" works, but seems to never end: Iteration 3297, level is 0.0414072 (-27.6585 dB). Iteration 3298, level is 0.0414074 (-27.6584 dB). Iteration 3299, level is 0.0414064 (-27.6587 dB). Iteration 3300, level is 0.041406 (-27.6587 dB). .....
"./dbmeasure hw:0 hw.csv" fails with this message: "Cannot set sample format: Invalid argument"
The DR range of software ( 16 bits audio data ) need to be same as the range of hardware volume control if you want ths slider move at same scale
i.e. if PA only use one hardware volume control of -48dB to 0 but the DR range of 16 bits audio is 96dB , PA have to scale up the dB value by two
The best way is of course to sum the DB range of all hardware volume controls in the audio path of the codec to get a DB range of value close to -96dB to 0 (i.e. need to use the value of the Volume Knob widget )
However the softvol plugin is in the software side , you have to verify the step of the solfware volume control "PCM Playback volume" behave as it expected
The easy way is to play a full amplitude of sine wave to "front" device and record it using an analog loop cable with 0dB capture gain , try to lower the PCM volume and observe the amplitude of the recorded sine wave is decreased at the correct ratio
2010/4/10 Nicolo' Chieffo nicolo.chieffo@gmail.com
DMBEASURE
There's still no way to run the measurement with "pulse" because of the previous error:Iteration 1, level is 0 (-inf dB). Volume level measured (0) was too high or too low. Please adjust mixer so that initial level is between 0.8 and 0.97. Test run canceled. Are you sure that the test has sense using the pulse device?
"./dbmeasure plug:front plug_front.csv" works, but seems to never end: Iteration 3297, level is 0.0414072 (-27.6585 dB). Iteration 3298, level is 0.0414074 (-27.6584 dB). Iteration 3299, level is 0.0414064 (-27.6587 dB). Iteration 3300, level is 0.041406 (-27.6587 dB). .....
"./dbmeasure hw:0 hw.csv" fails with this message: "Cannot set sample format: Invalid argument"
The sum the dB range of these two hardware volume controls are already -96dB to 0 as same as the DR of 16 bits digital audio data is 96dB
the point is that PA developer think the dB range of the pulseaudio master volume control is -inf dB to 0dB
control.18 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 64' comment.dbmin -4800 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value 27 }
control.7 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 64' comment.dbmin -4800 comment.dbmax 0 iface MIXER name 'Headphone Playback Volume' value.0 64 value.1 64 }
On Sat, Apr 10, 2010 at 11:27 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
the point is that PA developer think the dB range of the pulseaudio master volume control is -inf dB to 0dB
The range is 200 dB, since they use that value as -inf. Can you suggest something to tell to the pulseaudio developers?
2010/4/10 Nicolo' Chieffo nicolo.chieffo@gmail.com
On Sat, Apr 10, 2010 at 11:27 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
the point is that PA developer think the dB range of the pulseaudio
master
volume control is -inf dB to 0dB
The range is 200 dB, since they use that value as -inf. Can you suggest something to tell to the pulseaudio developers?
As your reported bug is "pulseaudio master volume is scaled differently as alsa master"
the answer is because "pulseaudio master volume" has a different dB ranage from the alsa master volume control
2010/4/10 Nicolo' Chieffo nicolo.chieffo@gmail.com
On Sat, Apr 10, 2010 at 11:27 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
the point is that PA developer think the dB range of the pulseaudio
master
volume control is -inf dB to 0dB
The range is 200 dB, since they use that value as -inf. Can you suggest something to tell to the pulseaudio developers?
http://pulseaudio.org/ticket/580
"pulseaudio master volume is scaled differently as alsa master"
If I were pulseaudio developer , I will close your bugs as marked it as invalid since the "Pulseaudio master volume control" is not as same as "ALSA master volume control"
2010/4/11 Nicolo' Chieffo nicolo.chieffo@gmail.com
I'm a bit confused... it's impossible that both bugs are invalid
if you still have any question in software atten , you should ask the expert -. the openal developer since openal rely on dB to calculate the correct sound level for distance *attenuation*
2010/4/9 Nicolo' Chieffo nicolo.chieffo@gmail.com
You are saying that the range for my card is 96 dB, do you mean that the audio specs are wrong? I mean, at 0 the volume is not audible, so I'm wondering why the -inf "switch register" is not activated (inside the chip)...
Have you ever studied the 92HD71B datasheet ?
In the Figure 11. 92HD71B Widget Diagram , NID 10 ( DAC) -95.25 dB to 0dB with 0.75 dB step
You have to ask alsa developer why the control did not return this range
2010/4/9 Nicolo' Chieffo nicolo.chieffo@gmail.com
On Fri, Apr 9, 2010 at 1:11 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
Mute Capable (1 bit) reports if the respective amplifier is capable of muting. Muting implies a –infinity gain (no sound passes), but the actual performance is determined by the hardware.
http://thread.gmane.org/gmane.linux.alsa.devel/39262/focus=16100
I think you missed the point, I'll explain again. I'm not complaining that at 0% the audio is not mute, as the bug you linked.
Clemens Ladisch (developer) 2004-11-09 09:26 The AD1981B's datasheet says that the maximum attenuation is 46.5 dB (which conforms to the AC'97 specification). To mute, use Mute.
In fact my problem is that at 0% I get mute, but I shouldn't (as reported by that developer), since the max attenuation is not -inf, but -48 dB. So if you prefer, you could see this issue from a different point of view: at -48 dB the audio should be still audible, but it's not.
so you have to decide where the issue resides (but definitely not in pulseaudio) a) it is ok that the audio is mute at 0% (in this case you have to declare -inf dB) b) the audio level is really -48 dB (in this case the volume shouldn't be cut off completely, but simply quite low) Which one do you prefer?
http://en.wikipedia.org/wiki/Decibel
In electronics, the decibel is often used to express power or amplitude ratios (gains), in preference to arithmetic ratios or percentages. One advantage is that the total decibel gain of a series of components (such as amplifers and attenuators) can be calculated simply by summing the decibel gains of the individual components.
2010/4/9 Nicolo' Chieffo nicolo.chieffo@gmail.com
On Fri, Apr 9, 2010 at 1:11 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
Mute Capable (1 bit) reports if the respective amplifier is capable of muting. Muting implies a –infinity gain (no sound passes), but the actual performance is determined by the hardware.
http://thread.gmane.org/gmane.linux.alsa.devel/39262/focus=16100
I think you missed the point, I'll explain again. I'm not complaining that at 0% the audio is not mute, as the bug you linked.
Clemens Ladisch (developer) 2004-11-09 09:26 The AD1981B's datasheet says that the maximum attenuation is 46.5 dB (which conforms to the AC'97 specification). To mute, use Mute.
In fact my problem is that at 0% I get mute, but I shouldn't (as reported by that developer), since the max attenuation is not -inf, but -48 dB. So if you prefer, you could see this issue from a different point of view: at -48 dB the audio should be still audible, but it's not.
so you have to decide where the issue resides (but definitely not in pulseaudio) a) it is ok that the audio is mute at 0% (in this case you have to declare -inf dB) b) the audio level is really -48 dB (in this case the volume shouldn't be cut off completely, but simply quite low) Which one do you prefer?
if you had read studied the bug report
"On my Compaq R3070 laptop setting Master and Master Mono controls to 0 does not result in no sound out. I still get audio at a low level."
The user only set Master and Master mono controls to 0.
http://www.analog.com/en/audiovideo-products/audio-codecs/ad1981b/products/p...
Refer to Figure 1 THe functional BLock Diagram , you should notice that there is another volume control in the audio path from DAC to LINE_OUT
The Master Volume and Master mono control have dB range from -46.5dB to 0dB
But the PCM Out volume control has dB range of -34.5dB to +12 dB
That is you have to sum the atten of the hardware volume controls in the audio path
2010/4/8 Nicolo' Chieffo nicolo.chieffo@gmail.com
I'm sorry but I found out that I gave you wrong values of "amixer -D pulse": I just discovered that when I lower the alsa master volume, in some occasions the PCM volume goes to 99%, so now I will put it to 100% and check the pulse volume again.
0 dB = 65536 [100%] -3 dB = 57520 [88%] -6 dB = 52057 [79%] -12 dB = 41034 [63%] -24 dB = 26090 [40%] -48 dB = 10151 [15%]
You have to ask PA developer since "PCM" is a softvol control with access 'user' and dbmin -51dB
control.24 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 255 value.1 255 }
HDA-Intel.pcm.front.0 { @args [ CARD ] @args.CARD { type string } type softvol slave.pcm { type hw card $CARD } control { name "PCM Playback Volume" card $CARD } }
2010/4/8 Nicolo' Chieffo nicolo.chieffo@gmail.com
I'm sorry but I found out that I gave you wrong values of "amixer -D pulse": I just discovered that when I lower the alsa master volume, in some occasions the PCM volume goes to 99%, so now I will put it to 100% and check the pulse volume again.
0 dB = 65536 [100%] -3 dB = 57520 [88%] -6 dB = 52057 [79%] -12 dB = 41034 [63%] -24 dB = 26090 [40%] -48 dB = 10151 [15%]
So again, the only problem is that -48 dB IS mute, but it's not declared as mute. This is the real issue.
For AC97 codec , both Master and PCM are hardware volume controls
Register 02 - control the stereo master volume Register 18 - PCM out volume
But on HDA , PCM is most likely a software volume control just like pulseaudio volume control
participants (9)
-
Alan Horstmann -
Clemens Ladisch -
Colin Guthrie -
James Courtier-Dutton -
Lennart Poettering -
Mark Brown -
Nicolo' Chieffo -
Raymond Yau -
Reddy, MR Swami