[alsa-devel] wrong decibel data?
superquad.vortex2 at gmail.com
Thu Apr 22 03:16:44 CEST 2010
2010/4/21 Colin Guthrie <gmane at colin.guthr.ie>
> 'Twas brillig, and Raymond Yau at 21/04/10 03:32 did gyre and gimble:
> > 2010/4/17 Colin Guthrie <gmane at colin.guthr.ie>
> >> 'Twas brillig, and Raymond Yau at 16/04/10 14:48 did gyre and gimble:
> >>> 2010/4/3 Colin Guthrie <gmane at 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
> > unwilling to provide info to debug your case , at least you have to
> > 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
> > propose to throw away the volume slider of the application. (i.e. why
> > allow pavucontrol to change the per-application volume ?
> 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
> > 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
> > 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
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
More information about the Alsa-devel