[alsa-devel] wrong decibel data?

Raymond Yau superquad.vortex2 at gmail.com
Wed Jun 23 03:15:31 CEST 2010

2010/6/23 Colin Guthrie <gmane at colin.guthr.ie>

> 'Twas brillig, and Raymond Yau at 22/06/10 16:29 did gyre and gimble:
> > 2010/6/22 Colin Guthrie <gmane at 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 ?


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

More information about the Alsa-devel mailing list