[arch-general] change in mount behaviour?

Ralf Mardorf ralf.mardorf at alice-dsl.net
Sun Jan 29 18:14:19 EST 2012


On Sun, 2012-01-29 at 23:33 +0100, Tom Gundersen wrote:
> On Sun, Jan 29, 2012 at 11:04 PM, Ralf Mardorf
> <ralf.mardorf at alice-dsl.net> wrote:
> > Since the sound device is ok when using ALSA only, the +4dBu vs -10dBV
> > information or any ratio dB to fader position or what ever you mean,
> > must be somewhere provided correctly by ALSA. If such a dB issue should
> > be the cause, than I suspect PA pulls this information from the wrong
> > place. What happens, when using Arts or any other sound server?
> 
> ALSA is not using this information in the same way (if at all). It is
> a well known problem that PA will act crazy if the dB values from ALSA
> are wrong, but ALSA itself mostly does not care (because the user is
> setting all the mixer level themselves, unlike in PA where there are
> heuristics doing clever stuff).
> 
> To learn more, run test and find the correct values that can be
> reported to ALSA, see: <http://pulseaudio.org/wiki/BadDecibel>.
> 
> > In case of doubt file a bug report to ALSA and PA.
> 
> Sure, but do the test above first. It will save some time.
> 
> > IIRC the sound device works correctly since years for ALSA, just when
> > using PA there's distortion. Is it reasonable to assume that there's a
> > bug for ALSA?
> 
> In this case, this is a well known class of bugs, so yes that's
> reasonable (but not certain).
> 
> > Perhaps an user error? If the device should support +4dBu and -10dBV,
> > than the user perhaps missed to choose the correct level. Nor ALSA
> > neither PA does know what equipment is connected to the audio IOs.
> 
> The user should not need to know about dB levels when using PA, so
> this is a software bug (somewhere).

The +4dBu and -10dBV issue is related to the analog IOs and the
connected audio equipment, so it's impossible for any software to know
what dB to choose, since they can't detect the connected analog gear.

This is another issue:

"If (when flat volumes are enabled in PulseAudio) the playback volume of
one stream changes whenever another stream is played, this is most
likely caused be incorrect dB attenuation data exposed by the ALSA
kernel driver. [snip] There's a temporary workaround to make PA skip the
invalid dB data. But ha! I won't write down how that works here, to make
sure that you really file that bug. Muahaha. Mauahahahahah! "

I'm not sure if I translated the complete text correctly.

Especially this is hard to understand:

"If the third and fourth parameter to dbverify are ommited, the tool
will test the loudest volume setting against the softest one. If those
arguments are specified the tool will compare these two discrete
volumes. It is advisable to play around with these values to compare
multiple volume steps of the hardware. It is especially wise to pick
your own values if the lowest hw volume setting is too silent to be
audible. That said it might make sense to omit these arguments when
starting your testing. This will then also show you the available volume
step range of your card and you can then pick other values to tes from
that range.

The tool will play a 1s sine wave twice and in a loop, and attenuate it
once in software and once in hardware. The effect should be that the
wave should have the same volume both times if the dB information is
reliable. If the dB data is not correct, then they will have different
volumes. [snip] If this listening test reveals that the dB information
of your driver is not correct"

What I'm able to translate is very strange.



More information about the arch-general mailing list