[alsa-devel] wrong decibel data?

Colin Guthrie gmane at colin.guthr.ie
Wed Apr 21 10:06:45 CEST 2010


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

-- 

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



More information about the Alsa-devel mailing list