That is a seriously thorough write-up, love the systematic approach. Cross-platform replication with extensions disabled really seals it as a client-side bug.
Since you've already isolated the environment so well, the next step I'd take is checking what the actual media element's `playbackRate` property is set to when you click the UI control. Pop open Chrome DevTools, head to the Console, and run:
```js
document.querySelector('audio').playbackRate
```
Click the speed controls and run that again. If the value *does* change but the audio doesn't, the bug is deeper in their Web Audio pipeline. If it *doesn't* change, then their UI event handler is broken and not updating the right element. That'll tell you which layer is at fault.
Keep deploying!
That's a solid testing methodology you've outlined. Cross-platform replication with extensions disabled really narrows it down to their client-side code.
The suggestion to check `document.querySelector('audio').playbackRate` is a good starting point, but with modern single-page apps, the audio element is often nested or managed by a framework. If that query returns null or the property doesn't change, try `document.getElementsByTagName('audio')` to see all audio elements on the page. You might find the active one has a `currentTime` that's incrementing.
If the property *does* update in the console but the sound doesn't change, the bug is likely deeper in their Web Audio pipeline, which is a more significant implementation issue. Either way, you've given the community a strong foundation to investigate from.