I've been conducting a series of benchmarking tests on various AI meeting assistants, and MeetGeek consistently shows a significant latency issue when processing recordings longer than 60 minutes. For a tool whose primary function is to transcribe, summarize, and extract insights, this is a critical performance bottleneck.
Based on my analysis, the slowdown appears to be non-linear. A 30-minute meeting might be processed in approximately 10-15 minutes. However, a 90-minute meeting often takes 60+ minutes to return a full summary and actionable items. This suggests the processing pipeline may have sequential dependencies or resource constraints that don't scale well.
Several factors could contribute to this:
* **Audio preprocessing and diarization:** The initial step of separating speakers can be computationally expensive, and algorithms may have O(n²) complexity in some implementations.
* **Batch processing vs. streaming:** If the system waits for the entire audio file to upload before beginning any processing, it introduces a fixed delay before the first computation even starts.
* **Summary generation on full context:** Many LLM-based summarizers process the entire transcript at once for coherence. With long contexts, this inference time increases substantially, especially if using a larger model for quality.
Has anyone from the engineering team or the community reverse-engineered the workflow? I'm particularly interested in the configuration of their pipeline. A tool like this should ideally employ a streaming architecture for transcription and incremental processing to provide low-latency initial outputs, even for long sessions.
For users dealing with lengthy strategic sessions or workshops, this delay undermines the utility of having a "quick" summary while the discussion is still fresh. I've found that for meetings exceeding two hours, competing tools with more aggressive parallel processing often deliver a basic transcript 40-50% faster, though sometimes at a slight cost to summary accuracy.
Benchmarks > marketing.
BenchMark
Your observation about non-linear scaling is almost certainly correct. The bottleneck likely isn't just one step, but cumulative, compounding latency across a sequential pipeline. You mentioned batch processing, which is a huge factor - that initial upload delay is pure dead time.
The most impactful sequential dependency is probably the summary generation. If their architecture is naive, they're feeding the entire, massive transcript into a single LLM context window for summarization. That operation doesn't scale linearly with token count; the computational cost and time can increase exponentially due to attention mechanisms. They might be hitting rate limits on a third-party LLM API for large payloads.
A more efficient design would use a map-reduce approach: chunk the transcript, summarize sections in parallel, then produce a final summary of summaries. The fact they aren't doing this suggests either a rushed engineering trade-off or a cost-saving measure, as parallel processing consumes more compute resources.
p-value < 0.05 or bust