[pulseaudio-tickets] [PulseAudio] #848: Loud noise for pa_stream_flush()

[PulseAudio]

#848: Loud noise for pa_stream_flush()
------------------------+---------------------------------------------------
  Reporter:  mschwendt  |       Owner:  lennart                                 
      Type:  defect     |      Status:  new                                     
 Milestone:             |   Component:  daemon                                  
Resolution:             |    Keywords:  very loud short sound on stream flushing
------------------------+---------------------------------------------------

Comment(by tanuk):

 Replying to [comment:7 NNN]:
 > I don't want to disable flat volumes. I like the way it do its work.

 Here's an idea: make it possible to enable the user-visible part of flat
 volumes and the under-the-cover hw-volume-follows-highest-stream-volume
 part independently of each other. There's no need for them to be tied to
 each other. (I'm not convinced that the user-visible part is such a great
 idea, but the hw-volume stuff makes sense.)

 > I've read the alsa-devel thread and Mark Brown advised to do volume
 updates on zero - not to the sink value, as i understood. It will avoid
 all noises at the end of playback. It is simple to check this  by running
 an extra client with volume=0. When first client closes connection PA sets
 h/w volume not to the sink volume but to the level of extra client
 (volume=0).

 I don't understand this paragraph. My understanding of the message from
 Mark where he says something about "zero" is about doing updates on zero-
 crossing. Audio signal normally oscillates around zero. The idea of doing
 volume adjustment at zero-crossing is that the hardware delays any volume
 update requests until the audio sample value changes from positive to
 negative or vice versa - at that point the sample value is zero or very
 close to it, and changing the volume (ie. changing the sample multiplier)
 doesn't cause any significant jump between consequent samples.

 Doing that in Pulseaudio too might make sense, but using zero-crossing
 detection fixes different issues than the one discussed here. Here the
 problem is that pulseaudio does hardware volume changes without accounting
 for the delay between the time when pulseaudio gives data to the sound
 card and the time when that data actually gets to the sound card's
 physical output and to the speakers.

 The discussion that Colin linked to seems to be about how to do the delay
 accounting perfectly, and apparently it's not possible, at least
 currently. However, just taking account the reported playback latency
 would probably go a long way, even though it would still leave some
 glitches.

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