تأخیر لوپبک صوتی و محدودیت تست پخش

بیشتر تستهای صوتی پخش و دریافت را میسنجند نه تأخیر رفتوبرگشت؛ عددی که تعیین میکند ضبط با کلیک ممکن باشد، تماس طبیعی و صدای فضایی دقیق باشد. سیستمی میتواند تستهای پخش را بگذراند ولی تأخیری فاجعهبار داشته باشد. این راهنما اندازهگیری و کاهش تأخیر را آموزش میدهد.

هر بررسی سختافزاری به یک شکل آغاز میشود. بلندگوی جدید را وصل میکنید، تنِ تست را پخش میکنید، مطمئن میشوید صدا بیرون میآید و سراغ کار بعدی میروید. میکروفون را وصل میکنید، صحبت میکنید، میبینید نشانگر سطح میپرد و ادامه میدهید. این دو تست تأیید میکنند که مسیر خروجی و مسیر ورودی شما کار میکنند؛ اما هیچکدام پرسشی را نمیسنجند که واقعاً تعیین میکند آیا سیستم صوتی شما از پس کار واقعی برمیآید: یک صدا چقدر طول میکشد تا از میکروفون، از میان کامپیوتر، از بلندگوها بیرون بیاید؟

به آن عدد، تأخیر رفتوبرگشت میگویند و بیسروصدا تعیین میکند سیستم شما صادقانه از پس کدام کارها برمیآید:

• ضبط موسیقی. نواختن همراه با کلیک یا ترک همراه مستلزم آن است که صدای خودتان تقریباً بیدرنگ به گوشتان برگردد. بالای حدود چهل میلیثانیه رفتوبرگشت، زمانبندیتان میلنگد، هر برداشت کسلکننده به گوش میرسد و هیچ مقدار تمرین هم درستش نمیکند. رابط‌های صوتی که یک کنترلر USB را با دستگاه‌های دیگر به اشتراک می‌گذارند نیز ممکن است از رقابت پهنای باند USB رنجندرند، که تأخیرهای ناگهانی را به تأخیرهای بافر اضافه می‌کند.
• برقراری گفتگو. تماس ویدیویی فقط وقتی طبیعی است که خط لوله صوتی منسجم بماند. تأخیر بیش از حد پژواک، گفتار رویهمافتاده و ریتم خشک و بریده تماس ماهوارهای میسازد.
• بازی با صدای فضایی. صدای موقعیتدار فقط وقتی کار میکند که صدا همگام با چیزی که میبینید برسد. وقتی مسیر صدا از تصویر عقب میماند، صدای قدمها و شلیکها از رویدادهای روی صفحه جدا میشود.

تست بلندگو و تست میکروفون شما به این پرسش پاسخ میدهند که «آیا کار میکند؟» تست تأخیر لوپبک به این پرسش پاسخ میدهد که «چقدر سریع؟» این صفحه توضیح میدهد تأخیر رفتوبرگشت چیست، از کجا میآید و چگونه پایین آورده میشود. ارقام این صفحه حاصل تجربه عمومی در میان پیکربندیهای فراوان سختافزار و نرمافزار است — یک راهاندازی واقعی ASIO روی Focusrite Scarlett 2i2 اعدادی متفاوت از کدک آنبورد Realtek در ویندوز ۱۱ میدهد. نتیجه شما با رابط، درایور و تنظیمات بافر خاص خودتان متفاوت خواهد بود.

تست تن، تأخیر را اندازه نمیگیرد

یک تست بلندگو یک تن، یک جاروب یا یک قطعه موسیقی را از مسیر خروجی پخش میکند و تأیید میکند صدا بیرون میآید. این یک بررسی کارکردی با نتیجه قبول یا رد است: کابل وصل است، درایور بارگذاری شده، صدا قطع نیست و مبدل دیجیتالبهآنالوگ زنده است. اگر تن را بشنوید، مسیر خروجی کار میکند. این همه چیزی است که این تست میتواند بگوید.

تست میکروفون هم برای جهت ورودی همین کار را میکند. آنچه میگویید را میگیرد، نشانگر سطح را نشان میدهد و تأیید میکند میکروفون، پیشتقویتکننده و مبدل آنالوگبهدیجیتال کار میکنند. باز هم نتیجه قبول یا رد است.

اندازهگیری تأخیر اصلاً گونهای دیگر از تست است. بهجای اینکه بپرسد آیا سیگنال میتواند از یک مسیر عبور کند، میپرسد عبور چقدر طول میکشد. روش ساده است: یک سیگنال شناختهشده — یک ایمپالس، یک کلیک، یک انفجار کوتاه — از خروجی میفرستید، در ورودی میگیرید و اختلاف زمانی بین ارسال و دریافت را محاسبه میکنید. همان اختلاف، تأخیر رفتوبرگشت است که بر حسب میلیثانیه بیان میشود.

این تمایز مهم است چون این دو اندازهگیری مستقل از هم هستند. یک سیستم میتواند از همه تستهای پخش بگذرد و در عین حال تأخیری فاجعهبار داشته باشد. بلندگوهای بلوتوث مثال کلاسیک است: آنها تن را وفادارانه بازتولید میکنند، پس تست بلندگو موفقیت را گزارش میکند، در حالی که کدک بیسیم صد تا صدوهشتاد میلیثانیه تأخیر اضافه میکند که هیچ تست پخشی هرگز متوجه آن نمیشود. تنی که صد و پنجاه میلیثانیه دیر میرسد، به بیان دقیق، همچنان در حال پخش است.

به همین دلیل فرض رایج — «بلندگوهایم خوب صدا میدهند، پس سیستم صوتیام خوب است» — برای هر کاری که به زمانبندی حساس است فرو میپاشد. کارکرد و زمانبندی دو محور جدا هستند. پیش از آنکه به سیستم خود برای ضبط، تماس یا بازی اعتماد کنید، به عددی نیاز دارید که تستهای پخش از نظر ساختاری قادر به تولید آن نیستند.

مراقب پرشدن بافر باشید

تأخیر رفتوبرگشت یک تأخیر واحد نیست؛ مجموع تأخیرهایی است که در هر مرحله میان کپسول میکروفون و مخروط بلندگو انباشته میشود. شناختن مسیر دقیقاً نشان میدهد میلیثانیههای شما کجا پنهان شدهاند:

1. بافر ورودی. مبدل آنالوگبهدیجیتال پیوسته نمونهبرداری میکند، اما سیستمعامل صدا را بهصورت بلوک تحویل میدهد. درایور منتظر میماند تا یک بافر کامل شود و بعد داده را به برنامه میدهد. در 48 کیلوهرتز پر شدن بافر 128 نمونهای 2.7 میلیثانیه طول میکشد — همان مدتی که صدای شما پیش از پردازش منتظر میماند. بیشتر سیستمها دو یا سه بافر را همزمان در گردش نگه میدارند. انتظار داشته باشید حدود پنج تا هشت میلیثانیه بگذرد تا برنامه نخستین نمونه را ببیند.
2. تبدیل آنالوگ به دیجیتال. مبدل برای نمونهبرداری، کوانتیزهکردن و ساعتدهی سیگنال زمان لازم دارد. روی سختافزار مصرفی این مرحله معمولاً یک تا سه میلیثانیه سهم میگیرد؛ رابطهای تخصصی بهتر عمل میکنند.
3. زمانبندی سیستمعامل. موتور صوتی برنامه شما را با تایمر بیدار میکند و بیدار شدن تابع زمانبندی عادی رشتههاست. در حالتهای اشتراکی، سیستمعامل جریان شما را هم با هر منبع صوتی دیگرِ سیستم میکس میکند و یک گذر پردازشی خودش اضافه میکند. این مرحله بسته به پلتفرم و بار، از چند میلیثانیه تا بیست میلیثانیه یا بیشتر سهم دارد. این همان مرحلهای است که لینوکس با PipeWire میتواند از ویندوز جلو بزند — و جایی که یک محیط دسکتاپ پرسروصدا میتواند بیسروصدا تأخیر شما را منفجر کند.
4. پردازش برنامه. نرمافزارِ سمتِ دریافت — ایستگاه کاری صوتی دیجیتال، زنجیره افکتها، گراف صوتی مرورگر — بلوک را پیش از ارسال به مرحله بعد پردازش میکند. کوچک است، اما بخشی از کل است.
5. تبدیل دیجیتال به آنالوگ. آینه مرحله دو است و یک تا سه میلیثانیه دیگر اضافه میکند، چون سیگنال پردازششده به ولتاژ آنالوگ تبدیل میشود.
6. بافر خروجی. نمونههای پردازششده در بافر خروجی منتظر میمانند تا مبدل آماده پخش آنها شود و حسابوکتاب اندازه بافرِ سمت ورودی تکرار میشود. در پیکربندیهای معمول پنج تا هشت میلیثانیه دیگر اضافه کنید.

مرحلهها را جمع بزنید و تأخیر رفتوبرگشت حالت اشتراکی روی یک کامپیوتر معمولی معمولاً بین سی تا شصت میلیثانیه قرار میگیرد — ارقام اندازهگیریشده زیر نمونههای توصیفی از سختافزار خاص هستند، نه مشخصات جهانی. در آزمون غیررسمی روی یک لپتاپ استاندارد ویندوز ۱۱ با کدک آنبورد Realtek ALC897 و بافر 128 نمونهای، اندازهگیریهای حالت اشتراکی نزدیک به سر بالایی این بازه مشاهده شد. با Behringer U-Phoria UM2 از طریق ASIO4ALL روی همان سختافزار، اندازهگیری به حدود پانزده میلیثانیه رسید. اینها مشاهدات تکدستگاهی بدون شرایط کنترلشده هستند؛ آنها نقطه مرجعِ فاصله معمول بین مسیر اشتراکی و مسیر ASIO را میدهند، نه مقادیر تضمینشده برای سختافزار شما. هیچ درایوری زمان تبدیل را حذف نمیکند — اما سربار بافر و زمانبندی که بخش غالب کل است، بهشدت کوچک میشود.

یک عدد، دو تعریف

نرمافزار صوتی بهندرت یک عدد واحد اعلام میکند. تنظیمات یک برنامه حرفهای را باز کنید و معمولاً دو عدد میبینید: تأخیر ورودی، یعنی زمان رسیدن صدا از میکروفون به برنامه، و تأخیر خروجی، یعنی زمان رسیدن صدا از برنامه به بلندگوها. درایورهایی مثل ASIO هر دو مقدار را جداگانه گزارش میکنند و مطالب بازاریابی اغلب عددی را نقل میکنند که بهتر به نظر میرسد.

تأخیر رفتوبرگشت مجموع این دو عدد بهعلاوه زمان پردازش خود برنامه است. اگر سیستمی بیست میلیثانیه یکطرفه اعلام کند، رفتوبرگشت تقریباً چهل میلیثانیه خواهد بود. کاربری که «تأخیر 20 میلیثانیه» را میخواند و فرض میکند همین تأخیری است که خواهد شنید، دو برابر اشتباه میکند — و این اشتباه رایج است، چون اعداد یکطرفه همانهایی هستند که روی برگه مشخصات چاپ میشوند.

این تمایز مهم است، چون چیزی که شما درک میکنید همیشه رفتوبرگشت است. وقتی نوازندهای صدای خودش یا سازش را مانیتور میکند، صدا باید از میکروفون بیرون بیاید، از سیستم عبور کند و پیش از شنیدهشدن به هدفون برگردد. این مسیر کامل است. عدد یکطرفه فقط نیمی از سفر را توصیف میکند.

برای یکدست ماندن بحث، همه اعداد این صفحه به تأخیر رفتوبرگشت اشاره دارند. وقتی اندازهگیری خود را با مشخصات محصول یا بنچمارک مقایسه میکنید، همیشه بررسی کنید که هر دو عدد همان نوع سفر را توصیف میکنند. مقایسه اندازهگیری رفتوبرگشت با مشخصات یکطرفه باعث میشود سیستم شما دو برابر کندتر از آنچه هست دیده شود.

سیستمعامل پیش از شما تصمیم میگیرد

همان میکروفون، همان بلندگوها و همان کابل روی سیستمعاملهای مختلف تأخیرهای بسیار متفاوتی تولید میکنند، چون هر پلتفرم صدا را از پشته نرمافزاری متفاوتی عبور میدهد. پشته تعیین میکند چقدر سربار بافر و زمانبندی به زمان تبدیلِ اجتنابناپذیر اضافه شود.

ویندوز: حالت اشتراکی، حالت اختصاصی و ASIO

ویندوز سه راه برای رسیدن به سختافزار ارائه میدهد و هر کدام نیمرخ تأخیر متفاوتی دارد:

• حالت اشتراکی WASAPI مسیر پیشفرضی است که هر برنامهای استفاده میکند، مگر اینکه چیز دیگری بخواهد (Microsoft Learn: WASAPI Shared Mode, 2023). همه صداها با هم میکس و با بافری محافظهکارانه تحویل میشوند. بازه تأخیر رفتوبرگشتِ معمولاً مشاهدهشده روی سیستمهای متعارف بین سیودو تا شصتوچهار میلیثانیه است، بسته به اندازه بافر و بار — اینها بازههای تجربه رایج هستند، نه مقادیر تضمینشده. Web Audio، WebRTC و پخش رسانه هر کدام مسیرهای کمی متفاوتی طی میکنند، اما همه از همین میکسر اشتراکی شروع میشوند.
• حالت اختصاصی WASAPI یا ASIO میکسر را دور میزند و به یک برنامه دسترسی مستقیم به دستگاه میدهد و معمولاً تأخیر را روی سختافزار متعارف به حدود ده میلیثانیه میرساند (Microsoft Learn: WASAPI Exclusive Mode, 2023). برای برنامههای بومی که آن را درخواست کنند در دسترس است؛ مرورگرها نمیتوانند.
• ASIO پروتکل درایوری است که کل پشته صوتی ویندوز را دور میزند و مستقیم با سختافزار رابط صحبت میکند (Steinberg: ASIO Host and Driver Guide v2.3, 2021). ASIO با یک رابط توانمند معمولاً به هشت تا پانزده میلیثانیه میرسد، گرچه اعداد دقیق به رابط خاص، نسخه درایور و پیکربندی بافر بستگی دارد. مرورگرها نمیتوانند از آن استفاده کنند.

macOS: Core Audio

چارچوب Core Audio اپل بهخوبی بهینه شده است و برنامههای بومی با تنظیمات بافر معقول بهطور رایج به هشت تا بیست میلیثانیه رفتوبرگشت میرسند. مسیر اشتراکی کارآمد است، پس حتی تأخیر اندازهگیریشده در مرورگر روی macOS معمولاً بهتر از ویندوز است. همچنان بالاتر از حداقل بومی میماند، چون مرورگر نمیتواند دسترسی اختصاصی به دستگاه بگیرد یا بافر را مطابق نیاز خودش تنظیم کند.

لینوکس: ALSA، PulseAudio و PipeWire

تأخیر لینوکس هدفی در حال تغییر است. ALSA، رابط درایور سطح پایین، سریع اما خاصِ هر برنامه است. PulseAudio از نظر تاریخی سربار بافری محسوسی روی آن اضافه میکرد. PipeWire، جایگزین مدرن، برای صوتی کمکمخاطره طراحی شده و وقتی درست پیکربندی شود میتواند با دیگر پلتفرمها برابری کند یا از آنها جلو بزند، اما نتایج با توزیع و راهاندازی بسیار متفاوت است.

در بیشتر پیکربندیها، مرورگر به مسیر اشتراکی محدود است. نمیتواند حالت اختصاصی درخواست کند، نمیتواند درایور ASIO بارگذاری کند و نمیتواند اولویت رشته صوتی خودش را بالا ببرد. پس تأخیر صوتی مرورگر معمولاً به سقف حالت اشتراکی پلتفرم شما نزدیکتر است — بهترین چیزی که مسیر مشارکتی در پیکربندیهای استاندارد میتواند تحویل دهد — در حالی که نرمافزار حرفهای بومی برای فرار از آن سقف ساخته شده است وقتی سختافزار و درایور اجازه دهند.

60 میلیثانیه واقعاً به چه معناست؟

یک عدد خام میلیثانیه تا وقتی آن را با کاری که قصد انجامش را دارید مقایسه نکنید، هیچ معنایی ندارد. مرزهای زیر راهنمای کلی است، نه استاندارد صدور گواهینامه حرفهای؛ مناسب بودنِ واقعی به کار خاص، چیدمان مانیتورینگ و محیط شنیداری شما بستگی دارد. چهار ناحیه دامنه عملی را پوشش میدهند:

• زیر 20 میلیثانیه — عالی. تولید موسیقی حرفهای اینجا راحت است. نوازندگان میتوانند با کلیک ترک بگیرند، صدای خود را با افکت مانیتور کنند و در زمان بنوازند، چون مسیر بازگشت عملاً آنی است. صدای فضایی در بازیها هم به تصویر قفل میماند.
• 20 تا 60 میلیثانیه — برای بیشتر کاربردها قابل قبول. پادکست، تماس ویدیویی، بازی عادی و ضبط غیررسمی همه خوب کار میکنند. ترک دقیق موسیقی نزدیک بالای این بازه آسیب میبیند: نوازندگان حس میکنند بازگشت صدای خودشان کمی کش میآید و کارهای ظریف بالای حدود چهل میلیثانیه بهوضوح سختتر میشوند.
• 60 تا 120 میلیثانیه — برای تولید مشکلآفرین، برای استفاده روزمره قابل قبول. کارائوکه، چت صوتی و شنیدن اشکالی ندارند. ضبط همراه با ترک پشتیبان واقعاً دشوار میشود و در بازیها صدا شروع به جداشدن از رویداد میکند و سرنخهای موقعیتی را که صدای فضایی به آنها وابسته است تضعیف میکند.
• بالای 120 میلیثانیه — ضعیف. کارهای حساس به زمانبندی عملاً ناممکن است. تماسها پژواک شنیداری پیدا میکنند، اجراها از هم گسسته به نظر میرسند و صدای فضایی حتی در استفاده روزمره اشتباه شنیده میشود. این ناحیه خانه طبیعی صدای بلوتوث و سیستمهای حالت اشتراکیِ بدپیکربندیشده است.

مرزهای ناحیه قضاوتی هستند، اما شکل کلی قابل اتکاست: تولید به کمترین اعداد نیاز دارد، گفتگو بیشتر را تحمل میکند و شنیدن غیررسمی بیشترین را. اندازهگیری رفتوبرگشت شما سیستم شما را دقیقاً در یک ناحیه قرار میدهد و همان قرارگیری میگوید کدامیک از کاربردهای موردنظرتان خوشایند خواهد بود و کدامیک با شما خواهد جنگید. این عدد را دم دست نگه دارید — نقطه مرجع همه بهینهسازیهای بخش بعد است.

سه اهرم: نرخ نمونهبرداری، بافر، درایور

سه کنترل تعیین میکنند تأخیر شما کجای مسیر فرود بیاید و در اثرگذاری برابر نیستند.

نرخ نمونهبرداری گذردهی خط لوله را تعیین میکند — چند بار در ثانیه صدا اندازهگیری شود — نه مستقیم تأخیر را. اما با زمانبندی بافر در تعامل است، چون بافر بر حسب نمونه سنجیده میشود: 128 نمونه در 44.1 کیلوهرتز 2.9 میلیثانیه طول میکشد ولی در 96 کیلوهرتز فقط 1.3 میلیثانیه، پس همان اندازه بافر در نرخهای مختلف نمونهبرداری به مدتزمانهای متفاوتی نگاشت میشود. نکته این است که نرخ بالاتر پردازش بیشتری در هر ثانیه میخواهد، که اغلب شما را مجبور میکند برای پایدار ماندن دوباره بافر را بزرگ کنید و سود را خنثی کند. دنبال 96 یا 192 کیلوهرتز رفتن معمولاً بافر بزرگتری را برای پایدار ماندن جریان تحمیل میکند، که میتواند سود نظری را خنثی کند یا همهچیز را کندتر کند. با نرخ نمونهبرداری مثل یک تنظیم گردش کار رفتار کنید، معمولاً 48 کیلوهرتز، نه مانند کنترل اصلی تأخیر. 48 کیلوهرتز به استاندارد واقعی صوتیِ همراستا با ویدیو تبدیل شد، چون بهراحتی روی نرخ فریم ویدیو یعنی 24، 25 و 30 فریمبرثانیه مینشیند؛ به همین دلیل هم خط لوله حرفهای صوتی-ویدیویی در همانجا پیشفرض میگیرد.

اندازه بافر اهرم اصلی تأخیر است. تعیین میکند پیش از پردازش چقدر صدا جمع شود و دو بار در مسیر رفتوبرگشت ظاهر میشود — یکبار سمت ورودی و یکبار سمت خروجی. نصف کردن بافر، آن بخش از تأخیر را نصف میکند، اما همچنین وقتی را که سیستم برای تحویل هر بلوک دارد نصف میکند و خطر زیرروی بافر را بالا میبرد: کلیکها، پاپها و قطعشدنها. ماتریس عملی در 48 کیلوهرتز به این شکل است:

• 64 نمونه — تقریباً 8 تا 12 میلیثانیه رفتوبرگشت روی سختافزار توانمند با ASIO یا حالت اختصاصی. رابطهای اقتصادی اغلب در این اندازه کلیک تولید میکنند.
• 128 نمونه — تقریباً 12 تا 20 میلیثانیه. نقطه شیرین رایج ASIO برای تولید.
• 256 نمونه — تقریباً 20 تا 35 میلیثانیه. اغلب کوچکترین اندازه پایدار در حالت اشتراکی.
• 512 نمونه — تقریباً 35 تا 60 میلیثانیه. امن اما بهوضوح کند.
• 1024 نمونه — تقریباً 60 تا 100 میلیثانیه. فقط برای استریم یا پخشی که تأخیر در آن بیاهمیت است.

درایور کف را تعیین میکند. ASIO و حالت اختصاصی اندازههای بافر 32 تا 128 نمونه را مجاز میکنند؛ حالت اشتراکی بالاتر کف میدهد؛ کدکهای بلوتوث هم پیش از آنکه بافرها اصلاً در نظر گرفته شوند، صد میلیثانیه یا بیشتر اضافه میکنند. هیچ تنظیم بافری نمیتواند از حداقل درایور پایینتر برود؛ برای همین درایور اولین اهرم است، نه آخرین.

مرورگر یک DAW نیست

یک مرورگر میتواند با استفاده از Web Audio API تأخیر رفتوبرگشت را تخمین بزند (MDN: Web Audio API, 2024)؛ این API یک ایمپالس را از خروجی زمانبندی میکند و سیگنال رسیده را در ورودی میکروفون میگیرد. اندازهگیری لوپبک معمول Web Audio روی یک لپتاپ در حالت اشتراکی معمولاً 55 تا 70 میلیثانیه گزارش میکند — چند برابر عدد ASIO — فاصلهای که مالیات مسیر اشتراکیِ مرورگر را نشان میدهد. زمان اندازهگیریشده شامل مسیر آکوستیک در هوا، مبدلهای بلندگو و میکروفون، پردازش حذف پژواک اتاق و کل پشته صوتی سیستم است. به آن تأخیر رفتوبرگشت آکوستیک میگویند و برای تماسهای مبتنی بر مرورگر، کارائوکه و بازیهای داخل تب، عددِ مرتبط است، اما معادل تأخیر رفتوبرگشت ASIO که نرمافزار صوتی حرفهای اندازه میگیرد نیست. در نظر داشته باشید که این اندازهگیری به یک مسیر آکوستیک واقعی بین بلندگو و میکروفون نیاز دارد؛ کنترل خودکار بهره، حذف نویز و حذف پژواک میتوانند شکل ایمپالس را تغییر دهند، و فاصله میکروفون، بازتابهای اتاق و تنظیمات بلندی همگی بر نتیجه اثر میگذارند.

کاری که مرورگر نمیتواند انجام دهد، رسیدن به بهترین حالت ممکن سختافزار است. باید از مسیر صوتی اشتراکی سیستمعامل استفاده کند، نمیتواند دسترسی اختصاصی به دستگاه بگیرد، نمیتواند درایور ASIO بارگذاری کند و نمیتواند اندازه بافر صوتی یا اولویت رشته خودش را کنترل کند. پس اندازهگیری، سقف حالت اشتراکی پلتفرم شما را بازتاب میدهد، نه حداقل حقیقی سختافزار.

همان سقف دقیقاً عدد درست برای کارهای مبتنی بر مرورگر است. تماسهای وب، بازیهای مرورگر، کارائوکه وب و هر چیز دیگری که داخل یک تب اجرا میشود، همگی در سطح سیستمعامل مسیر صوتی مرورگر را به اشتراک میگذارند، گرچه Web Audio، WebRTC و پخش رسانه در جزئیات متفاوتاند. اگر عدد اندازهگیریشده در مرورگر خوب باشد، همه کاربردهای مرورگر حس خوبی خواهند داشت. اگر بد باشد، نرمافزار بومی ممکن است همچنان نجاتتان دهد — اما مرورگر روی همان سختافزار و پیکربندی عموماً کندتر از نرمافزار بومی خواهد بود.

شش راه برای کاهش تأخیر

با ترتیب اثرگذاری روی مسئله کار کنید و به محض اینکه عددتان در ناحیهای فرود آمد که با آن میتوانید زندگی کنید، متوقف شوید:

1. اول حالت درایور را درست کنید. در ویندوز، درایور ASIO رابط صوتی خود را نصب کنید یا به حالت اختصاصی WASAPI بروید. این بزرگترین اهرم است و رایگان.
2. اندازه بافر را کم کنید. از 512 به 256، 128 و 64 نمونه پایین بیایید و هر تنظیم را امتحان کنید تا کلیک یا پاپ بشنوید؛ بعد یک پله بالا برگردید و بزرگترین بافری را نگه دارید که تمیز میماند.
3. نرخ نمونهبرداری را بررسی کنید. برای کار موسیقی و ویدیو از 48 کیلوهرتز استفاده کنید. دنبال 96 یا 192 کیلوهرتز رفتن معمولاً بافر بزرگتری را تحمیل میکند و نهایتاً کندتر تمام میشود.
4. برنامههای رقیب را ببندید. استریم، ضبط و تبهای شلوغ مرورگر زمان CPU را از رشته صوتی میدزدند و در اندازههای بافر کوچک زیرروی ایجاد میکنند.
5. به یک رابط صوتی فکر کنید. سختافزار اختصاصی مبدلهای بهتر، درایورهای ASIO درست و اندازههای بافری میآورد که صدای آنبورد به آنها نمیرسد.
6. اتصال باسیم را ترجیح دهید. برای هر کار حساس به زمانبندی، هدفون باسیم صد میلیثانیه یا بیشتر از بلوتوث بهتر است، فارغ از هر تنظیم دیگری.

هر قدم روی قدمهای قبلی سوار میشود. رفتن از حالت اشتراکی در 512 نمونه به ASIO در 128 نمونه معمولاً سیستمی را از پنجاه میلیثانیه به زیر بیست میبرد — تفاوت بین غیرقابل استفاده و حرفهای.

جمعبندی

تست پخش تأیید میکند بلندگوهای شما کار میکنند. تست لوپبک تأیید میکند که در زمانِ درست کار میکنند — و اینها پرسشهای متفاوتی با پاسخهای متفاوتاند. برای اعتبارسنجی مسیر خروجی، تست بلندگو و برای اعتبارسنجی مسیر ورودی، تست میکروفون را اجرا کنید. لطفاً توجه کنید که این سایت در حال حاضر ابزار اختصاصی اندازهگیری تأخیر لوپبک ارائه نمیکند؛ روش Web Audio API که در بالا توضیح داده شد به یک پیادهسازی جداگانه یا راهاندازی کنسول مرورگر نیاز دارد. از آن برای یادگیری تأخیر رفتوبرگشت آکوستیک استفاده کنید — همان چیزی که تعیین میکند ضبط، گفتگو و صدای فضایی روی دستگاه شما طبیعی حس شوند.

یک بار اندازه بگیرید و نتیجه را نگه دارید. زیر بیست میلیثانیه یعنی زمانبندی در سطح حرفهای. بیست تا شصت بیشتر کارهای روزمره را پوشش میدهد. بالای صد و بیست، هر کار حساس به زمانبندی با شما خواهد جنگید و درمان معمولاً با درایور شروع میشود، نه با سختافزار. اگر هرگز این عدد را اندازه نگرفتهاید، درباره هر کار صوتی وابسته به زمانبندی دارید حدس میزنید.