[pulseaudio-tickets] [PulseAudio] #896: Ignore lowest mixer level, via settings

[PulseAudio]

#896: Ignore lowest mixer level, via settings
--------------------------+-------------------------------------------------
  Reporter:  danutz       |       Owner:  lennart      
      Type:  enhancement  |      Status:  reopened     
 Milestone:               |   Component:  module-alsa-*
Resolution:               |    Keywords:               
--------------------------+-------------------------------------------------

Comment(by coling):

 I apologise if I wrote the wrong thing above when I wrote "perhaps in the
 kernel and perhaps in alsa". What I meant was that a bug I recently helped
 fixed turned out to be two separate bugs.

 To explain in more depth (although the thread I linked to above actually
 goes into a lot of detail) one part of the bug was specific to my hardware
 (a quirk in the kernel side) and one was very generic (alsa lib did not
 take that quirk into consideration - and so if any other drivers have
 implemented the quirk, it wouldn't be taken into consideration).

 To explain a little the API we use: snd_mixer_selem_set_playback_dB() from
 ALSA API. This API includes a "direction" argument. This argument allows
 us to say to alsa "please can I have -25dB, but if you can't do that give
 us something with less attenuation - e.g. -24.5dB". This argument is
 '''specifically designed''' to prevent over attenuation by apps which
 control via dBs.

 When the minimum value actually mutes, the goal of preventing over
 attenuation is clearly broken and this API call is clearly not producing
 the end result it should.

 It is very clear to me that this function itself, is the one that must be
 fixed to prevent this issue. Adding a hack or workaround in PA is just
 papering over cracks in lower layers and we have always stated that one of
 the primary goals of PA is to improve the overall audio stack and that
 requires fixing bugs in the right place. Add to that that we don't really
 know when a mixer level is at it's minimum (we just set via dB and rely on
 the direction argument) and we do not have any specific way to identify
 audio hardware with regards to a quirks database for recording which h/w
 is faulty.

 I am no ALSA developer, but as tanuk said, the bug tracker at alsa is
 totally worthless (I've tried to push several times for them to prevent
 new bug submissions, but it's never really gained much traction). Use the
 alsa-devel mailing list; it is much more productive. Also try not to get
 into conversations with Raymond about this stuff. While he can be helpful
 and communicative and occasionally has gems of information, he is usually
 very tangential. It is very hard for someone unfamiliar with the list to
 not get stuck in a loop in that way! I would very much direct your emails
 at Takashi, Jaroslav or Clemens who all have a very good understanding of
 this stuff and are the ones you rally need to get a hold off.

 I am hoping the alsa-lib fixes that address my issue will be available in
 a released version sometime soon (I believe an alsa-lib release will come
 shortly). It could be that this part of the fix is essential for your h/w
 too.

 If you supply a link to your alsa-info.sh script output (or attach it to
 this bug), I'll have a look and see if the TLV fixes in alsa-lib help in
 your case and if a kernel side fix is also needed and if necessary help
 you push it through to the appropriate alsa devs.

 I presume you have already tried the patches at the kernel side and alsa-
 lib side I pointed to earlier? Can you comment on the results of this when
 you tested?

-- 
Ticket URL: <http://pulseaudio.org/ticket/896#comment:11>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server