Loud noise for pa_stream_flush()

[mschwendt]

The lower an application's volume level, the louder the noise when calling pa_stream_flush(…) before changing a currently playing audio track. This is unbearable with some hardware configurations (and e.g. headphones).

It seems some applications and audio frameworks try to fight these symptoms by 'corking' the stream prior to flushing it, and 'uncorking' it afterwards. It's not clear whether that is 100%.

What is the reason for this loud noise caused by pa_stream_flush()? Please fix this.

[mschwendt]

$ cat /etc/fedora-release Fedora release 14 (Branched) $ rpm -q pulseaudio pulseaudio-0.9.21-6.fc13.x86_64

00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller

[NNN]

Can confirm this on Gentoo. pulseaudio 0.9.19

00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)

To reproduce and hear it you need working pulseaudio and mplayer. Just run mplayer -ao pulse somefile.flac then adjust volume to 50-70% and again but to 3-10, then Ctrl + C. You should hear short noise at 50-70% volume. That is very annoying.

For example, the sink volume has a higher value - 100% than the stream value - 10%, when the stream ends the volume in alsamixer (both Master and PCM) will revert back to the sink volume which is higher and has a splitsecond of audio left which is affected by this change.

[NNN]

P.S. this can be reproduced only with one stream at all, if you have more than one streams running - the volume level doesn't change after flushing first stream. It will revert back to the second stream's level. And no louder the noises at all. But always running one stream for this isn't a clue.

[coling]

This relates to the flat volumes feature in PA. If you disable this (daemon.conf) the issue will likely be avoided.

The problem comes mainly from the fact that adjusting mixer settings comes with no timing information or guarantees. Thus when we change the volume of the h/w back to it's "natural" level after a sound has finished playing, we cannot know for certain that the operation will happen at the exact moment the sound has actually finished. It is this lack of timing information on mixer changes that ultimately causes this (I believe). Details regarding this were asked on the alsa-devel mailing list not that long ago, but nothing solid has come from that as of yet I believe.

[mschwendt]

This relates to the flat volumes feature in PA.

=:-O

Indeed! Why is it the default then?

[...]

Btw, these are highly likely duplicates or just similar:

• http://pulseaudio.org/ticket/782 - loud "woof" when closing a player
• http://pulseaudio.org/ticket/822 - Closing the last stream on an ALSA sink causes distortion

[coling]

It's the default because it's a nice feature for most cases and can help to save power. The problem only kicks in when the stream volume is different from the sink volume, so it's also not super common.

Alsa thread is here: http://thread.gmane.org/gmane.linux.alsa.devel/70643

[NNN]

I don't want to disable flat volumes. I like the way it do its work. 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).

This example also shows that values of sink volume and h/w volume can be set up independently. Think we need a dirty hack to do the same thing without running any extra client.

[tanuk]

Replying to 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.

[tanuk]

Replying to coling:

It's the default because it's a nice feature for most cases and can help to save power.

With power saving, are you referring only to the reduced cpu-load in those cases where software volume adjustment can be avoided by using the hw amplifiers for stream volumes? I'm not aware of other savings. There is potential for more, but that potential isn't currently realized because of a thing that I think is a bug but someone might think it's a feature: currently, when nothing is playing, the hw volume is set to the sink reference volume. I think that's wrong, I think the hw volume should be set to minimum (maybe even muted?). That might save some power.

The reason someone might think the current behavior is a feature, is that this way the sink reference volume is better reflected in programs such as alsamixer. Minimizing the volume when nothing is playing might make alsamixer useless for controlling the sink volume. I think that doesn't matter, because pulseaudio can't give any guarantees anyway to retain any alsa mixer settings that the user changes directly with alsamixer.

Because of this, I think we should declare that bypassing pulseaudio and touching the alsa mixer directly isn't supported. This would also allow us to get rid of some complexity in the alsa modules, because they try to provide some fragile support for adapting to alsa mixer changes that are done by bypassing pulseaudio.

[coling]

Yeah the reason I mentioned it can save power is to offload software volume changes to the h/w. Of course this is often a fallacy with the h/w that makes use of alsa softvolume, but it's still worth considering.

I think ultimately that you are right about the "return to reference volume" thing. It's only really needed to keep alsa-mixer users happy. I don't think there is any need to drop it to zero either, just leaving it where it ends up is probably fine (if we did drop to zero, then wouldn't the loud woof currently heard turn out to be a clipping of the last little bit of sound?).

That said, even if people do use PA as their sound system, many users still want an alsa mixer. I think we need to address various other issue regarding this first (i.e. pass through of certain switches and controls to our GUIs), before we start to drop support for using an alsa mixer directly.

I am a little surprised to hear that the audio latency is not taken into account when changing volume. I very much assumed that it was and it was just the latency of the mixer change that ultimately caused problems. I've not really looked at that code, but how hard do you think it would be to in corporate that? Would getting the timing right be tricky (thinking about the issues involved, it perhaps is).

[tanuk]

Replying to coling:

I am a little surprised to hear that the audio latency is not taken into account when changing volume. I very much assumed that it was and it was just the latency of the mixer change that ultimately caused problems. I've not really looked at that code, but how hard do you think it would be to in corporate that? Would getting the timing right be tricky (thinking about the issues involved, it perhaps is).

It's a fair amount of work. Luckily, that work has already been mostly done: patches for implementing delayed hw volume application were sent in February: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-February/006743.html

Don't rush to merge those patches. Insider information: an improved set of patches is expected to appear soon on the mailing list :)