Hunting Down Audio Bugs - a view from behind the scenes
All what should become a great mess later started with a single bug report some time back:
" HTML5 Live stream has bad sound and video"
(dramatic music effect)
found by Gwendragon, who in the following events tested, logged and categorized a lot of audio stuff too.
This bug happened only on a single site, which is well frequented in one country, but otherwise rather irrelevant.
Back then we could only check if it works for us - which it did for those who tested it after spoofing the user agent - so this bug was set to "cannot reproduce" (which means: Closed) after contacting the site owner because at that time it appeared to be a problem for the site to fix.
Usually this is the end of the story, the developers can only fix what they see and what they can analyze, and if it works for the testers and the developers, it can't be broken, right?
Sadly not.
Somehow we managed to forget one operating system (OS) during the check, which was partly my fault, because usually I use that OS while testing.
All was good until the next report came in for exactly the same site. We checked it again (usual procedure, no bug gets closed unchecked), this time with the right OS too and the result was: !
Not only that - suddenly reports about dozens of other sites started popping up!
PANIC!!!
Well, no panic, but no real solution in sight either, which is quite frustrating because at that time all of the developers, who can fix this kind of bugs, were heavily burdened with really important stuff like frozen UI or crashes, which of course have a higher priority, especially because super traffic-heavy sites like YT, Vimeo etc. worked well - but of course those audio bugs were constantly nagging in the background.
Then, one day, it was finally possible to assign a developer to the problem, but the fix was everything but easy.
One of the first things was to find out where it breaks and what exactly breaks - which sounds easy enough but isn't, especially if you have to deal with the codecs inside of the OS because prohibitive license fees from the MPEG-LA and the Fraunhofer institute forbid to bundle the full ffmpeg+aac codec in binary form to Vivaldi, no thanks to them.
(Linux users might have noticed by now, that they are not hit by this because they can steal re-purpose the original Chrome codecs hosted in the usual repositories - a luxury the owners of other OSs don't have)
The first thing to do was to add some sophisticated debugging code to the internal builds which can provide log files for the sites that were affected by the issue.
Said and done, we testers (both the employed and we volunteers) went through all of the bugs and created tons of big log files which we dumped on the poor Developer. After some time some of us became experienced enough to identify some common problems so that we could "Duplicate" bugs (meaning link together bugs that have the identical cause) on some kind of master bugs (usually the bug where the exact problem was first seen).
One thing all of those bugs had in common was the interaction between Vivaldi and the OS codecs...