wasapi: prevent audio pops on startup, resume, and seek - #2545
Conversation
|
Converting to draft until I can come up with something better with clearer explanations. Most of the current state was done by "throw shit at the wall and see what sticks" principle, and even though it works, I don't understand most of what's going on behind the scenes really. |
|
Throwing shit is a good approach for the first iteration, but before merging, we need a better understanding of the situation. Certainly the existing code isn't as good as it should be, and suffers from the same problem; I guess the author didn't have a full understanding either. But new code solves problems, and never introduces new problems. But when I merge changes to existing code, that may introduce new problems, therefore merging code changes needs more thorough review. Because likely you will be gone when the bug reports start coming in, and then it's my problem. I suggest you try to finish the "primed" patch first, but a simpler version as I described in the comment. It is easy to see that this needs to be improved and how. |
Two things make WASAPI playback click audibly: starting the client while its buffer holds little data (a short burst of audio followed by silence), and restarting it without dropping data left over from a previous Stop() (stale audio gets replayed). Seeking additionally left the client running, rendering silence until new data arrived. Fix this by waiting for a full endpoint buffer before starting, by stopping the client on seek, and by calling Reset() just before starting again - never directly after Stop(). Also check for a full endpoint buffer before GetBuffer(), so the early exit no longer releases a buffer that was never acquired.
2 participants
Fixes annoying audio pops in the wasapi output caused by sample waveform discontinuities. Most of them, at least. The remaining ones can only be masked by something like fade in/out, which MPD doesn't have.