Hector Martin

More info in the PR description, but on a more personal side: when I first ran into this, and reported it upstream months ago, the OBS devs said "Max audio buffering reached!" was the problem. That warning was treated as some kind of catastrophic, restart-OBS-to-fix-it issue.

It seemed it was just accepted that buggy or misbehaving audio sources could cause that situation, and when they did, all of OBS's audio processing was expected to stop working properly, and you had to restart the whole app.

This always rubbed me the wrong way. First, because I *knew* from logs that I had gotten that error *hours* before the stream actually fell over. Second, because something is clearly wrong if a buffer never shrinks, can only grow, and once it reaches a max your app falls over.

Obviously if multiple audio sources cannot be reconciled in time due to time slip, *some* audio drop-outs need to happen. But they should neither affect everything globally, nor cause a persistent problem forever.

Now I know that it was just another dumb bug. The buffer size increase codepath corrects those slipping sources, but once that no longer runs or sources slip too much, OBS's audio mixing code just... couldn't deal with them, instead breaking entirely.

So the patch just makes it detect that situation and drop late audio from that source (and possibly reset it to pending) before the whole audio mixing tree gets poisoned by audio data from the past. And now everything is fine.