audio: Remove checkAudioBuffering

[prgmitchell]

Description

This removes the checkAudioBuffering function from the log analyzer.

Motivation and Context

In all of my time in support, apart from the application audio capture buffering issues which have been solved, this has rarely contributed to the interaction and almost always detracts from it. Nearly every instance of this error relates to sources that are not actually using audio or sources that hit max audio buffering, reset, and then had no issues all without the user noticing. Most see this critical error and assume it is the cause of their unrelated issue. This usually leads to a conversation explaining that if a user is not actually experiencing any audio issues you would expect (cutting out or audio going totally silent), this can simply be ignored anyways.

How Has This Been Tested?

Still works fine, nothing else depends on this function.

Types of changes

• Tweak (non-breaking change to improve existing functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[mihawk90]

There's a typo on the Commit and PR heading, a missing i

[RytoEX]

Apparently, this is diagnostically valuable on macOS if a user is having troubles with their audio interface.

[Penwy]

I can attest that this check, throughout the now two an a half years I have done support for, has been nothing but a bane, and a cause for time wasted unnecessarily convincing users it is not in fact causing any issues.

If the check is indeed useful on macos (which I personally cannot speak to), I'd suggest changing it to only show on macos, or at the very least demote it to an info instead of a critical, but, please make it so it stops showing as a critical on windows.

[prgmitchell]

I still think this needs to go, I just took the time to look through every log posted in #macos-support on the Discord server that had a "Max Audio Buffering" flag from this year and I was able to find a single instance where it may have actually been relevant to their issue but no one responded. At the same time I found a few instances in that channel alone that people had asked about the message but it was unrelated to their problem and they had no audio issues presenting at all.

[RytoEX]

I defer to @jcm93 on the subject of the diagnostic value on macOS.

[prgmitchell]

Sounds good, and just to clarify for @jcm93 I am not saying there is no value to the max audio buffering message in the log...it can be very helpful when looking to see what is going on when a specific device is having buffering issues. What I am saying is that it being shown by the log analyzer creates many more questions for a user than it does answers and will often send someone on the wrong path trying to solve something unrelated.

[jcm93]

Yeah, as I said out of band I have no objection to it going away if it's just noise on other systems, particularly since it doesn't look like there's extant plumbing here to easily disable checks based on OS. And even then, the flag is basically a "yep, your audio source had an issue", when a support conversation is typically geared around why that's happening, which this warning doesn't help with, so even in the best case it has very limited usefulness.