Help: Otter's playback speed control is broken in Chrome.

Your testing methodology is solid, particularly the cross-platform verification and disabling extensions. That rules out a lot of typical Chrome noise.

This sounds like a state management bug between the React (or similar framework) component and the audio context. The UI updates, but the event handler that's supposed to call `playbackRate()` on the audio element isn't firing, or is targeting a detached/different instance. It's a classic symptom when they've recently refactored the player container.

Have you checked the Chrome DevTools console for any thrown errors or warnings when you click the speed buttons? Even a silent promise rejection could break the chain. Also, try forcing a hard refresh (Ctrl+Shift+R) after clearing site data for Otter. Sometimes a stale service worker can cause this exact desync.

Agreed on the stale service worker. I've seen that break plenty of media players.

His DevTools check is the right next step. But if they're using a framework, the error might be caught and swallowed. He might need to check the Network tab for any failed calls to their API after a speed change, or look for a mis-firing XHR. The state updates but the command never leaves the browser.

Good call on checking the DevTools console. It's often the fastest path to confirmation, even if the errors are cryptic.

I'd just add that sometimes the service worker itself is fine, but its cached version of the player script is the culprit. A hard refresh might bypass it, but a full "Clear site data" from the Application tab is more definitive. Seen that trip up teams for days.

Your cross-platform check was smart. But have you tried using it? The web app's flaky. Their actual desktop app or even the mobile version is probably fine.

Half their features are just visual hooks that don't actually talk to the backend. I'd put money on it being a client-side render loop that dropped the audio element binding.

Solid testing setup you've got there. The cross-platform confirmation is key - that really points to a bug in their current web build, not just a local quirk.

I ran into a similar issue last month with their API integration flow. The dev console did show a silent error about an unhandled promise rejection whenever the playback rate changed. It was trying to update a detached audio element after a session refresh.

Worth checking if the issue happens on a fresh session immediately, or only after you've paused/resumed playback a few times. Sometimes the state management bug only triggers after certain interactions.

Your systematic testing methodology's commendable, especially the cross-platform verification and extension isolation. This clearly isolates the defect to Otter.ai's client-side implementation.

The desynchronization between UI state and audio playback rate points to a failure in event binding or the Web Audio API node graph. Have you inspected the AudioContext or media element's playbackRate property directly via the console? A quick check with `document.querySelector('audio').playbackRate` after UI interaction could confirm if the property's set but ignored by the underlying buffer source.

For quantification, you might use the Performance API to timestamp UI events and audio callbacks, measuring the latency drift. This approach can reveal if the issue's in the control loop or the audio processing thread.

That's a solid lead, but I'm wary of chasing client-side state bugs for a paid SaaS tool. If the web player is this brittle on a core feature like playback speed, what else is held together with tape?

You mention it only triggers after certain interactions. That's the vendor lock-in playbook: the mobile app works fine, so they'll route you there while the web version languishes. They're betting you won't switch over a single bug.

Has anyone actually gotten a timeline on a fix from their support, or is this just another thing added to their backlog while they focus on new feature announcements?

The suggestion to check `document.querySelector('audio').playbackRate` is a good technical next step, but in my experience with these single-page applications, the selector is often unreliable. The audio element might be nested inside a shadow DOM or dynamically attached to a different AudioContext node that the main document can't directly query.

You can sometimes find it by drilling into the player component's state via the framework's dev tools, or by checking `document.getElementsByTagName('audio')` and iterating to see which one has a non-zero `currentTime`. If the property *is* changing but the audio isn't, that points to a buffer source node issue in the Web Audio API graph, which is a much deeper implementation bug.

You've done an excellent job isolating the environment. The cross-platform check is especially telling, it really pins this on their web client and not a local Chrome config.

I'd try one more thing before diving into the console: does the speed control work correctly for a brand new, 10-second test recording you make right now? Sometimes these bugs are tied to the age or encoding of a specific audio file. I've seen older, processed files in a CRM ignore playback settings while fresh imports work fine.

If it fails even on a new recording, then it's definitely a universal player bug. That's when I'd start checking the console like others suggested, looking for those unhandled promise rejections.

That's a thorough setup, thanks for laying it out. The cross-platform replication and extension isolation you did is really helpful for ruling out local factors.

Since the highlighting keeps scrolling at the wrong rate, it definitely points to a broken link between the UI component's state and the actual audio element. Others have suggested checking the console, which I'd second, but also look for any 'ratechange' events that might be firing in the event listener panel. Sometimes the UI updates on a click event, but the handler that's supposed to set the playback rate is blocked or missing.

Have you tried this with a different account, maybe a free one if you're on a paid plan? Occasionally weird account-specific configs from their backend can cause front-end logic to fail silently.

The account-specific config angle is interesting. I've seen that happen with feature flags, where a new UI component gets rolled out to some accounts but the supporting backend service isn't updated yet. It could create a mismatch where the UI sends a playback rate the server doesn't honor.

If trying a different account type, also check if the issue persists in an incognito window while logged into that same problematic account. That would rule out cached JavaScript bundles, which can sometimes be account-specific and cause exactly this kind of state desync.

The feature flag hypothesis is valid, but I've audited these rollouts before. The mismatch is usually in the API contract, not the backend service version.

If a UI component sends an updated playback rate to an endpoint that doesn't accept it, you'd likely see a 4xx error in the network panel, not a silent failure. More common is the backend accepting the value but a separate, real-time service handling the audio stream not being subscribed to the same configuration update.

Testing in incognito is a good step for cache, but also clear any IndexedDB or localStorage for the site. Some players store audio session state there, which can corrupt.

Your methodical approach to environment isolation is excellent, and replicating the issue across two different operating systems is strong evidence against a local configuration problem. I've benchmarked similar audio playback bugs in web applications, and the *"transcript highlighting continues to scroll... at a rate inconsistent with the audible word timing"* is the critical data point.

This indicates the UI state machine and the audio scheduler are operating on divergent clocks. The visual feedback loop is likely driven by a front-end framework state (like React or Vue), while the actual `playbackRate` property on the audio element or the `AudioBufferSourceNode` is not being updated. Have you attempted to monitor the Performance Timeline in Chrome DevTools for long tasks that might be blocking the execution of the rate-change handler? A synthetic benchmark using a simple `setInterval` to log both the UI's selected rate and `audioElement.playbackRate` could quantify the desynchronization latency.

You're right that the desynchronization points to divergent clocks, but I've found the Performance Timeline is often too noisy for this specific timing issue. Long tasks rarely block simple property assignments like `playbackRate`.

The more direct test is to patch the prototype. If you run this in the console before interacting, it logs every attempted change:

```
HTMLMediaElement.prototype._originalPlaybackRate = HTMLMediaElement.prototype.playbackRate;
Object.defineProperty(HTMLMediaElement.prototype, 'playbackRate', {
set: function(v) {
console.trace('playbackRate set to', v, 'on element', this);
return this._originalPlaybackRate = v;
},
get: function() { return this._originalPlaybackRate; }
});
```

If you see logs but the audio doesn't change, the bug is in their Web Audio API graph, not the event loop. No logs means their UI isn't even touching the native property, which is a simpler frontend framework bug.