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@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.