بیشتر تأخیر در ترجمهٔ زنده انتظار است: برای جریان، برای کلمهٔ بعد، برای جمله. تنها بخشی که در اختیار شماست حالت تأخیر است: تأخیر کمتر، یا اصلاح کمتر.
شنونده‌ای که ترجمهٔ زنده را می‌خواند، هر خط را چند ثانیه پس از آنکه گوینده آن را گفته می‌بیند. این فاصله یک تأخیر نیست، بلکه چند تأخیر است که در امتداد یک زنجیره روی هم جمع می‌شوند، و بیشترشان نوعی انتظار هستند. دانستن اینکه هر انتظار مربوط به کدام بخش است، انتخاب حالت تأخیر را آسان می‌کند و به توسعه‌دهنده‌ای که نمایش‌دهنده‌ای برای متن می‌سازد می‌گوید چه چیزی را و کی نشان دهد.
یک معیار مفید پیش از عددها: یک مترجم همزمان انسانی معمولاً دو تا چهار ثانیه پشت سر گوینده حرف می‌زند. مترجمان به این فاصله «تأخیر گوش تا صدا» می‌گویند. برای زبان‌هایی که فعل در پایان جمله می‌آید، به‌جای صبر کردن برای فعل، آن را پیش‌بینی می‌کنند یا جمله را به تکه‌هایی می‌شکنند که هر یک به‌تنهایی معنا داشته باشد. یک یا دو ثانیه تأخیر نقص نرم‌افزار نیست؛ تقریباً همان چیزی است که یک مترجم بسیار خوب هم دارد.
هر رونویسی زنده در VocalStack از همان مراحل، به همان ترتیب می‌گذرد و هر مرحله منتظر مرحلهٔ پیش از خودش می‌ماند.
متن زبان اصلی تقریباً همان‌گونه که گفته می‌شود به خواننده می‌رسد. ترجمه یک یا دو ثانیه بعد می‌آید، و جملهٔ گفته‌شده پس از ترجمه‌اش می‌رسد؛ به همین دلیل کلیپ صوتی همیشه آخرین چیزی است که می‌رسد. اولین اثر دیدنی این زنجیره، اما خیلی پیش از هر صدایی رخ می‌دهد: خود متن حرکت می‌کند.
اولین چیزی که مردم در یک متن زنده می‌بینند این است که تازه‌ترین کلمات جابه‌جا می‌شوند. عبارتی ظاهر می‌شود، تغییر می‌کند و سرانجام ثابت می‌شود. این کار مرحلهٔ پیش‌نویس است و دلیلش برای هر بازشناس گفتاری صادق است.
یک بازشناس گفتار یک کلمه را با نگاه کردن به کلمهٔ بعدی‌اش تثبیت می‌کند. «I scream» و «ice cream» در زبان انگلیسی تا رسیدن کلمهٔ بعد یکسان به نظر می‌رسند؛ یک «s» در انتهای کلمه ممکن است متعلق به همین کلمه باشد یا کلمهٔ بعد. تا وقتی صدایی سمت راست کلمه نباشد، املای آن حدس است. پس تازه‌ترین کلمات در هر متن زنده همیشه کم‌اطمینان‌ترین‌ها هستند. پیش‌نویس فقط همان حدس است که زودتر نشان داده می‌شود، نه اینکه پنهان بماند.
هر پیش‌نویس کل بخش زندهٔ انتهای متن را جایگزین می‌کند: کلماتی که از آخرین ثبت شنیده شده‌اند و هنوز در حال تغییرند. ثبت نهایی است. هرگز تغییر نمی‌کند، زمان‌بندی سطح کلمه را دارد، و ثبت‌ها بدون فاصله شماره‌گذاری می‌شوند تا خواننده بفهمد یکی را از دست نداده است.
برای توسعه‌دهنده، این تنها قاعده‌ای است که API بلادرنگ بر آن پافشاری می‌کند: هر بخش ثبت‌شده را نمایش دهید، سپس آخرین پیش‌نویس را پس از آن‌ها نشان دهید، و وقتی ثبتی می‌رسد پیش‌نویس را پاک کنید. افزودن پیش‌نویس‌ها به‌جای جایگزینی‌شان متن تکراری و لرزان تولید می‌کند؛ ثبت فقط بخش انتهایی را مصرف می‌کند. راهنمای WebSocket دقیقاً یک نمایش‌دهنده را بر همین اساس می‌سازد.
برای میزبان، جابه‌جایی متن بهای تأخیر کم است. نشان دادن کلمات پیش از تمام شدن عبارت است که متن را زنده نشان می‌دهد. اما ترجمه این ترفند را نمی‌تواند داشته باشد، زیرا یک کلمه را می‌شود از نیمهٔ عبارت حدس زد، ولی یک ترجمه را نمی‌شود.
ترتیب کلمات دلیل این است که ترجمه نمی‌تواند با سرعت پیش‌نویس پیش برود. فعل در آلمانی ممکن است در پایان بند بیاید و در ژاپنی فعل همیشه آخر است. هر مترجمی برای ترجمهٔ درست به کل بند نیاز دارد. ترجمهٔ کلمه‌به‌کلمه تکه‌هایی به شنونده می‌دهد که وقتی بند تمام می‌شود باید دوباره خوانده شوند. زبان آلمانی مترجمان همزمان را از خیلی پیش از آنکه نرم‌افزار سراغش برود، وادار کرده است تا برای فعل صبر کنند.
بنابراین VocalStack جمله‌ها را ترجمه می‌کند، نه بخش‌ها. جمله‌ها به‌طور پیش‌فرض روشن‌اند، و با روشن بودن آن‌ها، سرور ثبت‌ها را در یک جمله گرد می‌آورد و کل آن را ترجمه می‌کند. تا وقتی جمله باز است ترجمه‌اش موقت است؛ پس از بسته شدن جمله، ترجمه نهایی می‌شود. خواننده برای هر جمله یک مدخل نگه می‌دارد و با رسیدن به‌روزرسانی‌ها آن را جایگزین می‌کند.
گفتار هم بیشتر منتظر می‌ماند. فقط جملهٔ بسته‌شده خوانده می‌شود، زیرا جمله‌ای که هنوز در حال تغییر است با هر بازنگری دوباره از نو ساخته و صدا می‌شد. جملهٔ بلند به تکه‌هایی خوانده می‌شود، تا اولین تکه بتواند پخش شود در حالی که بقیه ساخته می‌شوند.
با خاموش بودن جمله‌ها، هر ثبت قاب ترجمهٔ خودش را می‌گیرد. این مسیر هیچ انتظاری ندارد، اما جمله‌های کامل خیلی بهتر خوانده می‌شوند.
همهٔ این انتظارها از لحظه‌ای سنجیده می‌شوند که صدا به VocalStack می‌رسد. برای بسیاری از پخش‌ها، صدا پیش از رسیدن به VocalStack هم دیر شده بود.
وقتی منبع یک جریان است نه میکروفون، صدا پیش از هر رونویسی از قبل عقب است. این صدا از لبهٔ زندهٔ جریان، یعنی تازه‌ترین لحظه‌ای که جریان منتشر کرده، عقب‌تر است.
یک جریان صوتی ساده با HTTP، همان نوعی که بیشتر ایستگاه‌های رادیویی اینترنتی منتشر می‌کنند، معمولاً یک تا سه ثانیه عقب است. سرور یک بافر انفجاری نگه می‌دارد: چند ثانیه از صدای اخیر که یک‌جا فرستاده می‌شود تا پخش‌کنندهٔ شنوندهٔ تازه بدون لکنت شروع شود. همهٔ شنوندگان، از جمله VocalStack، به همان اندازه عقب به جریان می‌پیوندند. HLS بدتر است: فهرست‌های پخش آن کلاینت را سه بخش پشت لبهٔ زنده شروع می‌کنند که در عمل، بسته به طول بخش‌ها، چند ثانیه تا نیم دقیقه می‌شود. DASH استاندارد معمولاً در همان بازهٔ HLS است؛ فقط نسخهٔ کم‌تأخیر آن زیر آن می‌رود. «زنده»ی یک ایستگاه شاید به همان معنایی زنده باشد که یک نامهٔ «تازه» است.
این ارقام تقریبی‌اند و متعلق به جریان‌اند، نه به رونویسی: هیچ تنظیمی در سمت VocalStack نمی‌تواند آن‌ها را پس بگیرد. اگر آن ثانیه‌ها برای یک رویداد مهم‌اند، صدا را از یک میکروفون یا یک انکودر بدهید، نه از یک جریان عمومی. تأخیر جریان پیش از آنکه VocalStack کلمه‌ای بشنود ثابت شده است؛ حالت تأخیر تنها چیزی است که واقعاً می‌توانید جابه‌جایش کنید.
حالت تأخیر فقط یک کار می‌کند: تعادل میان تأخیر و دقت را تعیین می‌کند. این تنظیم هنگام ساخت رونویسی زنده زیر Advanced قرار دارد و در برگهٔ Speed هنگام اجرا. آنجا نشان روی AUTO، SPEED یا ACCURACY است (Fast به‌صورت SPEED نمایش داده می‌شود). در API، session.update این حالت را در میانهٔ جریان تغییر می‌دهد.
معامله همان چیزی است که نام‌ها نشان می‌دهند. Fast متن را زودتر بیرون می‌فرستد اما بیشتر آن را اصلاح می‌کند؛ Accuracy کمی بیشتر صبر می‌کند و کمتر اصلاح می‌کند. تماشاگری که نشسته و زیرنویس ترجمه را می‌خواند به‌ندرت یک ثانیهٔ اضافه را حس می‌کند، اما کلماتی که پیوسته عوض می‌شوند را حس می‌کند. به همین دلیل Accuracy اغلب تنظیم مهربان‌تری است، تا وقتی نمودار تأخیر صاف بماند. Auto نشان می‌دهد چه می‌کند: خطی که برای پر کردن یک شکاف تندتر شده، نشان FAST MODE را در متن میزبان دارد، با یادداشتی مبنی بر اینکه دقت در آن خط ممکن است پایین‌تر باشد.
هر حالتی باشد، رونویسی باید پیش از اولین کلمه آماده باشد، و آماده‌سازی آن تنها تأخیری است که زنجیره فقط یک بار می‌پردازد.
در برخی طرح‌ها، شروع یک رونویسی زنده چند ثانیه طول می‌کشد. این مدت به طرح بستگی دارد: ردیف Start-up speed در صفحهٔ قیمت‌گذاری از شروع سرد تا 15 ثانیه در پرداخت به‌ازای مصرف تا همیشه گرم در طرح Enterprise را نشان می‌دهد.
در API، این انتظار به‌صورت فریم‌های session.loading در هنگام شروع جلسه و سپس session.ready دیده می‌شود؛ کلاینت تنها پس از آن صدا می‌فرستد. شنونده‌ای که در این فاصله پیوند را باز کند می‌بیند: «زنده است. اولین خط به‌زودی ظاهر می‌شود.» وقتی رونویسی در حال اجراست، این تأخیر پشت سر گذاشته شده است و تنها پرسش باقی‌مانده این است که از تأخیر باقی‌مانده چقدر با خود می‌برید.
وقتی یک رونویسی زنده اجرا می‌شود، برگهٔ Speed میزبان نتیجهٔ جمع همهٔ این‌ها را نشان می‌دهد: فاصلهٔ کنونی میان گوینده و متن، با نشان حالت در کنارش، و نموداری از آن فاصله در طول ضبط با میانگین و بیشینه‌اش. در خود متن، خطی که دیر به شنوندگان رسیده، نشانی دارد که تعداد ثانیه‌های میان لحظهٔ گفته شدن و لحظهٔ رسیدنش را می‌دهد.
نموداری که پایین و صاف بماند نشان می‌دهد حالت با صدا سازگار است. نموداری که بالا برود نشان می‌دهد خط‌لوله دارد عقب می‌افتد. در حالت Accuracy، این ممکن است لحظهٔ رفتن به Auto باشد که تا بسته شدن فاصله، کمی از دقت را برای سرعت کنار می‌گذارد.
توسعه‌دهندگان به‌جای آن یک عدد می‌گیرند. وقتی یک جلسهٔ بلادرنگ پایان می‌یابد، session.done مقدار stats.realtimeFactor را دارد: مدت صوتِ رونویسی‌شده تقسیم بر زمانی که صرف رونویسی آن شده است. یک هشدار دربارهٔ قرارداد: در ادبیات بازشناسی گفتار، real-time factor معمولاً عکس این است، یعنی زمان پردازش بر مدت صدا، که در آن کمتر بهتر است. VocalStack آن را برعکس گزارش می‌کند، پس اینجا بیشتر بهتر است: یک جلسهٔ زنده نزدیک 1 است، و زیر 1 یعنی صدا سریع‌تر از سرعت پردازش خط‌لوله رسیده است.
هیچ‌کدام از این ثانیه‌ها اسرارآمیز نیستند. بعضی متعلق به جریان‌اند، بعضی به کلمه‌ای که منتظر کلمهٔ بعد است، بعضی به جمله‌ای که ترجمه به آن نیاز دارد، و بقیه به حالت تأخیری که انتخاب کرده‌اید. مرجع API جزئیات فریم‌به‌فریم را دارد، و نمایش زنده‌ای که در صفحهٔ اصلی است، زنجیره را در حال کار نشان می‌دهد.
