I've been evaluating Fireflies.ai for the past two weeks as part of a broader initiative to benchmark meeting intelligence platforms for our engineering teams. While the transcription accuracy and note generation are meeting our preliminary criteria, the playback experience in the web application is currently unusable for detailed analysis, which is a significant blocker.
The primary issue is severe audio choppiness and dropout during playback of recorded meetings. The audio stream does not maintain consistency; it cuts in and out every few seconds, making it impossible to follow the conversation or verify transcript accuracy against the source material. This occurs specifically during playback of already-processed recordings within the Fireflies.ai web interface, not during the live meeting capture itself.
My testing methodology so far has been systematic:
* **Browser Test Matrix:** I have replicated the issue across three different browser engines on macOS Sonoma 14.5:
* Chrome 125.0.6422.141 (Chromium)
* Safari 17.5 (WebKit)
* Firefox 126.0.1 (Gecko)
* **Network Conditions:** Conducted tests on both a corporate gigabit fiber connection (latency <5ms to major clouds) and a residential connection. No packet loss detected via MTR during tests. Performance issues persist on both.
* **Meeting Sources:** Tested with recordings sourced from Google Meet, Zoom, and direct MP3 uploads. The choppiness is present regardless of source.
* **Console Analysis:** The browser developer console shows no consistent stream errors, but periodic `AudioContext` state warnings and buffering events.
I have performed standard troubleshooting: clearing cache, disabling all extensions, and ensuring no system-level audio enhancements were active. The problem is isolated to the Fireflies web app; playback of the same meeting's source file (downloaded from Zoom/Meet) is flawless in native players.
My immediate questions for the community are:
1. Is this a known issue with a documented workaround, or is my experience an outlier?
2. Has anyone performed a network trace or deeper performance profiling on the audio streaming endpoint? I'm curious if the choppiness correlates with specific CDN regions or audio encoding profiles (e.g., Opus vs. AAC).
3. From an infrastructure perspective, could this be related to audio chunking or buffer management logic on the frontend? I've observed similar patterns in other web apps when the adaptive bitrate logic is overly aggressive.
Without reliable playback, the utility of the tool for post-meeting review is fundamentally compromised. I'm leaning towards a platform-level issue rather than a client-side one, given my test matrix. Any detailed technical insights or benchmark comparisons with other platforms (like Otter.ai or Fathom) on playback reliability would be greatly appreciated.
—chris
—chris
You've started the right way by controlling for browser and local network, but I think your methodology is missing the most probable layer: the CDN or object store delivering the audio fragments. When you say the audio cuts in and out every few seconds, that's classic of high packet loss or, more likely, high latency variance on the individual HTTP range requests the playback engine is making for the audio file.
I'd suggest opening your browser's developer tools (Network tab) during playback, filtering for `media` type, and examining the timeline of those requests. Look for:
* Time to First Byte (TTFB) spikes on sequential requests.
* Stalled requests.
* Whether the `Accept-Ranges: bytes` requests are being served from a single domain or a scatter of different CDN edge nodes.
The inconsistency across three browsers actually points away from client-side decoding and toward a network delivery problem common to all of them. Try a tool like `curl` or `wrk` to benchmark the latency to the specific host serving those media segments under load; you might see the jitter.
Every microsecond counts.
Oh wow, I never would've thought to check the Network tab for something like this. That's a really smart suggestion.
When you say to look at the timeline of requests, is there a specific thing you'd recommend I look for first? Like, should I just watch for any red lines or errors, or is there a number for TTFB I should consider "bad"?
I'm a bit nervous I'll be looking at it and not know what I'm seeing.
You've done a great job isolating the browser and network variables. That kind of systematic testing is exactly what I'd do first.
One thing I'd add to your methodology: try downloading the actual audio file from Fireflies (if they let you export the raw recording) and playing it locally in VLC or a similar player. If the download plays perfectly smooth, then you've confirmed the problem is squarely in their web player's streaming logic, not the audio encoding or the server's file storage. I've seen a few meeting platforms use a custom audio player that has a really aggressive buffer size or a flawed chunked-loading strategy, and that can cause the exact cut-in-out behavior you're describing.
Also, since you're on a corporate gigabit connection, have you tried a different network entirely? Sometimes corporate firewalls or proxy devices interfere with the range requests for media. A quick test on a personal hotspot or a VPN could rule out a middlebox messing with the TCP packets.
If you can reproduce the choppiness on a download + local playback, then I'd bet Fireflies is using some kind of audio format that their web player struggles to decode in real-time (maybe high-bitrate Opus or a weird multichannel encoding). Might be worth asking their support if they have a recommended player or a known issue with certain codecs.
api first