I've been conducting a rigorous evaluation of Sembly for the past three weeks, primarily for our post-incident review meetings which often exceed 90 minutes. I've encountered a consistent and critical issue: the Sembly tab in Chrome becomes completely unresponsive and crashes, typically between the 45- to 70-minute mark. This renders the entire recording and transcription process unreliable, which is a significant problem for archival and analysis.
My initial hypothesis was a resource exhaustion issue. To validate this, I set up a controlled benchmarking environment to monitor the tab's behavior. Here are the key observations from my monitoring session (Chrome 124.0.6367.91, macOS 14.4, 32GB RAM):
* **Memory Leak Pattern:** The Sembly tab's memory footprint starts at a reasonable ~250MB. However, it exhibits a near-linear increase, climbing to ~1.8GB before the crash. The V8 JavaScript heap snapshot shows a steady accumulation of `AudioNode` and `String` objects, which are never garbage collected.
* **CPU Profile:** The `TranscriptionWorker` thread maintains a sustained ~25% CPU utilization on a single core, which is expected. However, the main thread's "Scripting" time grows disproportionately over the meeting's duration, leading to increasing input latency before the final lockup.
* **Crash Point:** The tab consistently fails when the `AudioWorklet` attempts to allocate a new `Float32Array` for an audio processing buffer, resulting in a `DOMException: Could not allocate memory`.
I've attempted the following mitigations with no success:
1. Disabling all other Chrome extensions.
2. Using the "Pause" function within Sembly intermittently.
3. Lowering the meeting's audio input quality from the OS level.
My current workaround is to run Sembly in a completely isolated Chrome user profile with strict site isolation flags, but this is not a sustainable solution for the team.
**Core Questions for the Community:**
* Has anyone else performed similar resource profiling on Sembly's frontend? Are my findings consistent with your experience, particularly for meetings exceeding one hour?
* Is this a known issue with the current architecture of the web client? Should we be directing users to the desktop application as a mandatory requirement for longer sessions?
* From an engineering perspective, what would be the recommended configuration or flag to suggest to Sembly's support team? I'm thinking along the lines of a client-side buffer flush interval or a more aggressive garbage collection trigger for the audio pipeline.
I will be forwarding the detailed Chrome DevTools performance and memory timelines to their support, but I'm keen to hear if others have diagnosed this to a more granular level or found a viable configuration change.
—chris
—chris