Phần lớn độ trễ khi dịch trực tiếp là thời gian chờ: chờ luồng âm thanh, chờ từ tiếp theo, chờ hết câu. Phần bạn kiểm soát được là chế độ độ trễ: ít trễ hơn, hay ít lần sửa hơn.
Người nghe đang đọc bản dịch trực tiếp sẽ thấy mỗi dòng sau khi người nói đã nói ra vài giây. Khoảng cách đó không phải là một độ trễ duy nhất mà là nhiều độ trễ cộng dồn dọc theo một chuỗi, và phần lớn trong số đó thực chất là thời gian chờ. Hiểu được từng khoảng chờ là gì sẽ giúp việc chọn chế độ độ trễ trở nên dễ dàng, và cho nhà phát triển biết nên hiển thị gì trên trình đọc, và khi nào.
Trước khi xem các con số, có một mốc tham chiếu hữu ích: một thông dịch viên đồng thời thường nói chậm hơn người nói gốc khoảng hai đến bốn giây. Giới thông dịch gọi khoảng cách đó là ear-voice span, tức khoảng cách tai–giọng. Với các ngôn ngữ có động từ ở cuối câu, họ không chờ động từ mà đoán trước nó, hoặc chia câu thành những đoạn có thể đứng riêng. Một hoặc hai giây trễ không phải là lỗi của phần mềm; đó gần như là mức trễ của một thông dịch viên giỏi.
Mọi phiên phiên âm trực tiếp trên VocalStack đều đi qua cùng các bước, theo cùng thứ tự, và mỗi bước đều chờ bước trước nó.
Văn bản ngôn ngữ gốc đến tay người đọc gần như ngay khi được nói. Bản dịch đến sau một hoặc hai giây, và câu được nói ra đến trước bản dịch của nó, đó là lý do một đoạn giọng đọc luôn đến cuối cùng. Tuy vậy, dấu hiệu nhìn thấy đầu tiên của chuỗi xuất hiện từ rất lâu trước bất kỳ giọng đọc nào: chính văn bản bắt đầu thay đổi.
Điều đầu tiên người ta nhận ra ở một bản phiên âm trực tiếp là những từ mới nhất cứ di chuyển. Một cụm từ xuất hiện, thay đổi, rồi ổn định. Đó là bước bản nháp đang hoạt động, và nó tồn tại vì một lý do áp dụng cho mọi bộ nhận dạng giọng nói.
Bộ nhận dạng chỉ chốt một từ khi nhìn vào những gì đứng sau nó. "I scream" và "ice cream" nghe giống hệt nhau cho đến khi từ tiếp theo xuất hiện; chữ "s" ở cuối có thể thuộc về từ này hoặc từ sau. Khi chưa có âm thanh ở bên phải một từ, cách viết của nó vẫn chỉ là phỏng đoán, nên những từ mới nhất trong bất kỳ bản phiên âm trực tiếp nào luôn là những từ ít chắc chắn nhất. Bản nháp đơn giản là phỏng đoán đó, được hiển thị sớm thay vì bị giấu đi.
Mỗi bản nháp thay thế hoàn toàn phần đuôi trực tiếp: các từ nghe được kể từ lần xác nhận gần nhất, vẫn còn đang thay đổi. Bản xác nhận thì cố định. Nó không bao giờ thay đổi, mang theo thời gian ở mức từng từ, và các bản xác nhận được đánh số liên tục không bị đứt quãng, để người đọc biết nếu mình đã bỏ sót một bản.
Với nhà phát triển, đây là quy tắc duy nhất mà API thời gian thực yêu cầu: hiển thị mọi đoạn đã xác nhận, rồi đến bản nháp mới nhất đặt sau chúng, và xóa bản nháp khi một bản xác nhận đến. Nếu nối thêm bản nháp thay vì thay thế, văn bản sẽ bị lặp và nhấp nháy; bản xác nhận chỉ đơn giản là nuốt luôn phần đuôi. Hướng dẫn WebSocket xây dựng một trình đọc đúng theo cách này.
Với người tổ chức, việc văn bản di chuyển là cái giá của độ trễ thấp. Hiển thị từ trước khi cụm từ kết thúc là điều làm cho bản phiên âm có cảm giác trực tiếp. Tuy nhiên, bản dịch không thể dùng mánh đó, vì một từ có thể được đoán từ nửa cụm, nhưng một bản dịch thì không.
Thứ tự từ chính là lý do bản dịch không theo kịp bản nháp. Trong tiếng Đức, động từ có thể nằm ở cuối mệnh đề, còn tiếng Nhật đặt động từ ở cuối. Bất kỳ người dịch nào cũng cần toàn bộ mệnh đề trước khi có thể dịch đúng. Dịch từng từ sẽ đưa cho người nghe những mảnh rời rạc phải được ghép lại khi mệnh đề kết thúc. Người thông dịch đã phải chờ động từ tiếng Đức từ rất lâu trước khi phần mềm thử làm điều đó.
Vì vậy VocalStack dịch theo câu, không theo đoạn. Chế độ câu được bật mặc định, và khi bật, máy chủ ghép các bản xác nhận thành một câu rồi dịch trọn câu đó. Trong lúc câu còn mở, bản dịch chỉ mang tính tạm thời; khi câu đóng lại, bản dịch trở thành bản chính thức. Người đọc giữ một mục cho mỗi câu và thay thế nó khi có cập nhật.
Giọng đọc còn chờ lâu hơn nữa. Chỉ câu đã đóng mới được đọc thành tiếng, vì một câu còn đang thay đổi sẽ phải được tổng hợp lại sau mỗi lần sửa. Một câu dài được đọc theo từng đoạn, nên đoạn đầu có thể phát trong khi các đoạn còn lại đang được tạo.
Khi tắt chế độ câu, mỗi bản xác nhận sẽ có một khung dịch riêng. Cách này không phải chờ đợi gì, nhưng các câu trọn vẹn đọc dễ hiểu hơn nhiều.
Mọi khoảng chờ này đều được tính từ lúc âm thanh đến VocalStack. Với nhiều buổi phát sóng, âm thanh đã trễ sẵn khi đến nơi.
Khi nguồn là một luồng thay vì micro, âm thanh đã bị trễ trước khi được phiên âm. Nó chậm hơn điểm trực tiếp, tức khoảnh khắc mới nhất mà luồng đã phát.
Luồng âm thanh HTTP thông thường, loại mà hầu hết đài phát thanh trên internet sử dụng, thường trễ từ một đến ba giây. Máy chủ giữ một bộ đệm đột phát: vài giây âm thanh gần nhất, gửi cùng lúc để trình phát của người nghe mới có thể bắt đầu mà không bị khựng. Mọi người nghe, kể cả VocalStack, đều tham gia từ điểm lùi ấy. HLS còn chậm hơn: danh sách phát đưa client lùi lại ba đoạn so với điểm trực tiếp, nghĩa là trên thực tế từ vài giây đến nửa phút, tùy độ dài mỗi đoạn. DASH chuẩn thường nằm trong khoảng tương tự HLS; chỉ biến thể độ trễ thấp của nó mới xuống đáng kể dưới mức đó. Luồng "trực tiếp" của một đài có thể "trực tiếp" cũng giống như một bức thư cũ vẫn được gọi là thư mới.
Các con số này chỉ là ước lượng, và chúng thuộc về luồng, không thuộc về việc phiên âm: không có cài đặt nào phía VocalStack có thể lấy lại những giây đó. Nếu chúng quan trọng với một sự kiện, hãy đưa âm thanh vào từ micro hoặc bộ mã hóa thay vì từ luồng công khai. Độ trễ của luồng được cố định trước khi VocalStack nghe thấy một từ nào; chế độ độ trễ mới là thứ bạn thực sự có thể điều chỉnh.
Chế độ độ trễ chỉ làm một việc: đặt sự cân bằng giữa độ trễ và độ chính xác. Cài đặt này nằm trong mục Advanced khi tạo một phiên phiên âm trực tiếp, và trên tab Speed khi phiên đang chạy. Ở đó, nhãn hiển thị là AUTO, SPEED hoặc ACCURACY (Fast hiển thị là SPEED). Qua API, session.update thay đổi chế độ ngay giữa luồng.
Sự đánh đổi chính là điều tên gọi gợi ý. Fast đưa văn bản ra sớm hơn nhưng sửa lại nhiều hơn; Accuracy chậm hơn một chút và sửa ít hơn. Khán giả ngồi xem phụ đề dịch hiếm khi nhận ra thêm một giây, nhưng lại nhận ra những từ cứ thay đổi. Vì vậy Accuracy thường là lựa chọn dễ chịu hơn, miễn là biểu đồ độ trễ đi ngang. Auto thì cũng để lộ cách nó hoạt động: một dòng mà nó đẩy nhanh để thu hẹp khoảng cách sẽ mang huy hiệu FAST MODE trong bản phiên âm của người tổ chức, kèm ghi chú rằng độ chính xác ở dòng đó có thể thấp hơn.
Dù ở chế độ nào, bản phiên âm cũng phải sẵn sàng trước từ đầu tiên, và việc chuẩn bị đó là khoản trễ duy nhất mà chuỗi chỉ phải trả một lần.
Với một số gói, phiên phiên âm trực tiếp mất vài giây để bắt đầu. Thời gian này phụ thuộc vào gói: dòng Start-up speed trên trang bảng giá ghi từ khởi động nguội tối đa 15 giây với gói Trả theo mức dùng, đến luôn sẵn sàng với gói Enterprise.
Qua API, thời gian chờ hiện dưới dạng các khung session.loading trong lúc phiên khởi động, rồi đến session.ready; client chỉ gửi âm thanh sau đó. Người nghe mở liên kết trong lúc này sẽ thấy "Trực tiếp. Dòng đầu tiên sẽ xuất hiện trong giây lát." Khi phiên phiên âm đã chạy, độ trễ này đã qua, và câu hỏi duy nhất còn lại là bạn đang mang bao nhiêu phần độ trễ còn lại.
Khi một phiên phiên âm trực tiếp đang chạy, tab Speed của người tổ chức cho thấy tổng hợp của tất cả những điều trên: khoảng cách hiện tại giữa người nói và văn bản, cùng nhãn chế độ bên cạnh, và một biểu đồ khoảng cách đó xuyên suốt bản ghi, kèm giá trị trung bình và đỉnh. Trong bản phiên âm, một dòng đến tay người nghe muộn sẽ có huy hiệu ghi số giây từ lúc nó được nói đến lúc nó đến nơi.
Biểu đồ luôn thấp và phẳng nghĩa là chế độ phù hợp với âm thanh. Biểu đồ đi lên nghĩa là hệ thống đang tụt lại. Ở chế độ Accuracy, đó có thể là lúc nên chuyển sang Auto, chấp nhận giảm một chút độ chính xác để tăng tốc cho đến khi khoảng cách thu hẹp lại.
Nhà phát triển thì nhận một con số duy nhất. Khi một phiên thời gian thực kết thúc, session.done mang theo stats.realtimeFactor, tức là thời lượng âm thanh đã phiên âm chia cho thời gian đã dùng để phiên âm. Một lưu ý về quy ước: trong tài liệu nhận dạng giọng nói, real-time factor thường có nghĩa ngược lại, tức thời gian xử lý chia cho thời lượng âm thanh, và giá trị càng thấp càng tốt. VocalStack báo cáo theo chiều ngược lại, nên ở đây giá trị càng cao càng tốt: một phiên trực tiếp thường gần 1, còn dưới 1 nghĩa là âm thanh đến nhanh hơn mức hệ thống phiên âm kịp xử lý.
Không có giây nào trong số này là khó hiểu. Một phần thuộc về luồng, một phần thuộc về việc một từ phải chờ từ kế tiếp, một phần thuộc về câu mà bản dịch cần, và phần còn lại thuộc về chế độ độ trễ bạn đã chọn. Tài liệu API có chi tiết từng khung, và bản demo trên trang chủ cho thấy toàn bộ chuỗi đang chạy.
