Clicks when pausing audio with low frequency content

[daikazoku]

When pausing in mpv, if there is low frequency content, the speakers/headphones will pop.

A very short fade out and fade in, in the order of a few milliseconds, should be imperceptible and solve this issue.

[daikazoku]

I forgot to post an example of the problem: (WARNING, THIS IS LOUD!!)

mpv "https://www.youtube.com/watch?v=ymBlpL9gaXo"

[paulguy]

Due to the way audio works, when you interrupt a low frequency, high amplitude wave like that, there's a decent chance of getting a fast transition back to 0, which in contrast to the low frequency sine wave, is heard as a wide band bit of noise, or a click. If by chance it's paused closer to a 0 crossing, the click will be quieter or near silent. To confirm this though, download the audio using something like youtube-dl then try playing it in something else. Chances are you'll get the same result, unless that program has a fade out on stopping or pausing.

[daikazoku]

paulguy, I know that the problem is due to how audio works. However, it can be solved.

As I said, the way to fix this is to add a short fade in and fade out, so that the transition isn't as abrupt. Even a very simple linear fade should do the trick.

[paulguy]

Heh, missed that I guess. Oh well.

Other people can know the how and why now, then.

[ghost]

In my opinion this is the responsibility of the OS.

[daikazoku]

I disagree. I think the OS should play audio as close as what it's presented with as possible, but that's just my opinion.

An application should have the choice of having a more exact playback or processing the audio but fixing issues like these. For this reason I think it's more reasonable that the application is responsible for this.

Even if in theory the OS should be responsible for this, in practice, what OSs do it?

[ghost]

I think the OS should play audio as close as what it's presented with as possible,

And a mediaplayer shouldn't?

Even if in theory the OS should be responsible for this, in practice, what OSs do it?

Sorry I'm not going to add highly complicated code to mpv just for such weak reasons.

[daikazoku]

And a mediaplayer shouldn't?

My point is that the OS can't assume that the application doesn't need exact audio, but a media player can probably assume that a really short fade won't bother anyone (if this is the first report of this, though, apparently the problem doesn't bother anyone either).

Sorry I'm not going to add highly complicated code to mpv just for such weak reasons.

Oh well, I can't say anything about this. I have no idea about mpv's code. In theory, the implementation of a fade is extremely simple, in some random pseudocode (not tested and it's probably possible in a cleaner way):

audio[n] *= max(1 - ((now - fade.start) / fade.length), 0);

I don't know how that would look in mpv's source.
I may be underestimating how complex this is though.

Feel free to close the issue if you feel this is not worth it.

[ghost]

The problem is not with fading itself, but somehow detecting that the user is going to pause, and then playing audio for slightly longer (instead of just pausing), and all without causing A/V desync.

[haasn]

Instead of continuing to play the actual audio, would it suffice to simply take the currently signal value and hold it for a while long (decaying the amplitude towards 0)?

For “resume” behavior, you could just have the amplitude increase back up from 0 to full in a short curve.

But possibly the OS could do something like this exact behavior too; e.g. maybe pulseaudio could be modified to apply this sort of decay- and resume behavior when streams suddenly start or stop.

(Although that would require mpv to actually close/pause the stream when it's pausing, not sure what the current behavior is)

[ghost]

It uses the PA pause function (pa_stream_cork()).

[daikazoku]

Instead of continuing to play the actual audio, would it suffice to simply take the currently signal value and hold it for a while long (decaying the amplitude towards 0)?

I don't think so, but someone might correct me on this. I think it generates both a discontinuity in the signal (making it pop a bit anyway) and a lot of undesiderable, very low frequency content.