أدلة API

نظرة عامة على Realtime

عرّف الدخل المباشر، واختر Socket.IO أو HTTP، ووفّق حالة النتائج، وتعافَ بصورة محافظة.

يعني Realtime أن الصوت لا يزال يصل عند بدء النسخ أو التمييز. لا تجعل استجابة متدفقة الملف المرفوع المكتمل Realtime.

1. اختر وفق دورة حياة المصدر

حالة المصدر عند بدء المعالجةالاختيارالعقد
اجتماع أو بودكاست أو أرشيف طويل أو كبير مكتملBatch RESTارفع مرة، واستلم jobId، واستعلم عن عمل
وحدة محادثة واحدة مكتملة حساسة لزمن الاستجابةالنسخ Fast عبر audio_file في Socket.IO أو HTTP POST /realtime/http/sttأرسل الوحدة كلها، وأنهِ عند is_final: true
صوت لا يزال يصل من ميكروفون أو مكالمة أو مصدر مباشرASR أو التمييز عبر Realtimeأرسل PCM مؤطرًا عند وصوله، ووفّق الحالة المؤقتة والنهائية

يمكن لـTTS بث الخرج المولد، لكنه ليس دورة حياة دخل الصوت المباشر المعرّفة هنا. راجع أدلة النقل العملية لسلوك TTS.

2. اختر وسيلة النقل المباشر

الجانبSocket.IO مع SDK 0.18.0HTTP المؤطر المباشر
الغلاف المنشورJavaScript وPythonلا يوجد
الإعدادAPI_URL وAPI_KEY؛ ويستخدم SDK ‏/socket.io افتراضيًاAPI_URL وAPI_KEY؛ من دون مسار Socket.IO
دخل ASR المباشريرسل بث SDK الحدث audio_streamطلب POST /realtime/http/stt-stream واحد لكل مقطع مؤطر
دخل التمييز المباشريرسل بث SDK الحدث diarization_streamطلب POST /realtime/http/diarization-stream واحد لكل مقطع مؤطر
النتائجالحدثان transcription_result وdiarization_resultسجلات استجابة application/x-ndjson
مالك التأطيرينشئ SDK الإطارات ويوجهها حسب UUIDينشئ التطبيق كل ترويسة 18 بايت ويعيد استخدام UUID
مالك التنظيفأغلق البث ثم افصل العميلأرسل إطارًا نهائيًا، وأنهِ القراءات أو أوقفها، وأغلق أجسام الاستجابة

استخدم نقل SDK عندما يدعم وقت التشغيل Socket.IO. استخدم HTTP المباشر عندما لا يستطيع وقت التشغيل الموثوق استخدام Socket.IO ويمكنه تنفيذ عقد التأطير والاستجابة الدقيق بنفسه.

تتطلب وسيلتا النقل المباشر x-api-key وصوت PCM16 little-endian بتردد 16 kHz وأحادي القناة. ابدأهما من خلفية موثوقة. يحتوي كل إطار دخل 16 بايت UUID خامًا، وبايت أعلام، وبايت لغة، ثم PCM. تعرض أدلة النقل العملية أدناه التخطيط الدقيق.

3. أنشئ سجل حالة واحدًا لكل بث

قبل إرسال الصوت، أنشئ UUID جديدًا وسجل حالة يملكه التطبيق لذلك البث. تتبع:

  • id للبث وعداد وصول يعينه التطبيق؛
  • نصًا مؤقتًا واحدًا قابلاً للاستبدال؛
  • كلمات الأحداث النهائية المثبتة بترتيب الوصول المرصود؛
  • وصول إشارات speech-final وstream-final؛
  • مقاطع التمييز المغلقة والنشطة؛
  • أول خطأ منظم والمهلة الكلية.

افصل هذه الحالة عن المقبس أو قارئ HTTP. يجب ألا يمحو إغلاق النقل النص المثبت، ويجب ألا تستبدل استجابة مؤقتة متأخرة حالة أحدث أو نهائية.

4. وفّق ترتيب وصول ASR ونهائيته

تتضمن الاستجابة seq، لكن عقد Realtime العام الحالي لا يعرّف دلالات ترتيب أو تفرّد لها. عيّن رقم وصول محليًا، وتحقق من علمي النهائية في كل استجابة، وطبق التغييرات التالية:

الإشارةالمعنىإجراء الحالة
وصول حدث نتيجةحالة مرصودة جديدةسجل رقم وصول محليًا، وأبقِ seq القادمة من الخادم لبيانات التشخيص فقط
is_final: false وis_speech_final: falseنص مؤقتاستبدل العرض المؤقت الحالي
is_speech_final: trueاكتشف النموذج حد نهاية كلامثبّت كلمات ذلك الحدث بترتيب الوصول، ثم امسح القيمة المؤقتة التي حلت محلها بينما يمكن أن يستمر البث
is_final: trueالنتيجة النهائية لبث النسخثبّت ذلك الحدث مرة، وامسح النص المؤقت الذي حل محله، وعلّم نتيجة البث كطرفية

عندما يكون علما النهائية true في استجابة واحدة، ثبّتها مرة وسجل الحقيقتين. لا تستنتج أي علم من فترة هدوء أو اتصال مغلق أو اكتمال استدعاء close().

أنشئ SRT أو WebVTT من توقيت الكلمات النهائية فقط. يزيل RealtimeSubtitles التكرار حسب id:seq، ولذلك قد يدمج أحداثًا نهائية متميزة ما دام الخادم يرسل قيم seq غير متميزة. لهذا العقد، اجمع الكلمات النهائية بترتيب الوصول المرصود واعرضها باستخدام Subtitles.

5. وفّق التمييز كخط زمني متطور

لكل سجل diarization_result أو سجل تمييز عبر HTTP:

  1. احتفظ بـfinal_segments وأزل تكرارها؛ فهذه المقاطع المغلقة لا تتغير.
  2. استبدل مجموعة active_segments السابقة بأحدث مجموعة؛ فقد تتطور هذه المقاطع أو تصبح نهائية.
  3. عامل is_final: true كآخر استجابة لبث التمييز ذلك.
  4. وفّق أحدث خط زمني للمتحدثين مع توقيت الكلمات النهائية باستخدام قاعدة تداخل صريحة.

تمثل تسميات المتحدثين أدوارًا نسبية في هذا البث، لا هوية حقيقية.

6. أنهِ البث بمهل منفصلة وتنظيف صريح

استخدم مهلاً منفصلة محدودة للاتصال، والجلسة كلها، وكل إرسال أو قراءة، وانتظار النتيجة النهائية. ثم أنهِ بهذا الترتيب:

  1. أوقف منتج الصوت حتى لا يضيف PCM جديدًا إلى الطابور.
  2. أرسل إطار النهاية الموثق مرة واحدة بالضبط.
  3. انتظر فقط حتى مهلة النتيجة النهائية لإشارة النهائية المناسبة.
  4. سجل هل اكتمل الإنهاء أم انتهت مهلته أم فشل.
  5. حرر وسيلة النقل في كتلة finally أو سياق async.

في Realtime ASR ضمن SDK 0.18.0، يرسل stream.close(timeoutSeconds) في JavaScript و stream.close(timeout_seconds=...) في Python إطار النهاية، وينتظران حالة is_final على مستوى البروتوكول أو خطأ موجهًا أو المهلة المحددة. ويعودان عند انتهاء الانتظار بدلاً من إطلاق خطأ مهلة. لا يثبت ذلك العود وصول is_final؛ افحص الحالة التي سجلتها الاستدعاءات. أما is_speech_final فهو حد كلام فقط ولا ينهي انتظار الإغلاق. ويعيد مساعد التمييز كذلك أفضل خط زمني معروف إذا انتهت مهلة الانتظار النهائي.

بعد إنهاء البث، يجب أن تستدعي JavaScript الدالة disconnect() داخل finally؛ ويجب أن تخرج Python من سياق العميل غير المتزامن. في HTTP المباشر، ألغِ الطلب المنتهية مهلته وأغلق قارئ استجابته.

7. عامل نتيجة الانقطاع كحالة ملتبسة

لا تعرّف العقود العامة استئناف الجلسة ولا إعادة idempotent لإطارات الصوت. كما لا تضمن حالة الخادم التي تبقى بعد سقوط اتصال Socket.IO أو انقطاع طلب HTTP. تعافَ عبر حد بث جديد:

  1. أوقف تغذية البث القديم وأغلق وسيلة نقله.
  2. احتفظ بالنتائج المثبتة، وتجاهل النص المؤقت غير المحسوم، وعلّم فترة الصوت الملتبسة.
  3. لا تعد المحاولة إلا إذا سمح الخطأ المنظم وسياسة التطبيق بذلك وبقيت المهلة الكلية؛ قيّد التراجع وjitter وعدد المحاولات والزمن المنقضي.
  4. أعد الاتصال بـUUID جديد وأرسل إطار بدء جديدًا.
  5. افصل نتائج البث الجديد حتى يضم التطبيق الخطين الزمنيين المثبتين صراحة.

لا تعد استخدام UUID القديم أو تعيد الإطارات بافتراض إزالة الخادم لتكرارها. إذا احتفظ التطبيق بصوت الفترة الملتبسة، فعالجه عبر مسار تعافٍ صريح بدلاً من وصله صامتًا بالبث المباشر الجديد. راجع الأخطاء وحدود المعدل.

8. انتقل إلى وسيلة نقل ومرجع ووصفة

اختر وسيلة نقل واحدة، وشغّل أصغر بث مباشر ممثل لها، وتحقق من إشارة النهائية الصحيحة، واختبر مساري المهلة والانقطاع قبل الإنتاج.

في هذه الصفحة