[alsa-devel] wrong decibel data?

Colin Guthrie gmane at colin.guthr.ie
Mon Jun 14 13:03:22 CEST 2010


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

-- 

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