การวัด audio latency ของไมค์·ลำโพง

เผยแพร่ 2026-04-13 อ่าน 8 นาที

สรุป (TL;DR)

สภาพแวดล้อมที่เล่นกีตาร์ acoustic ผ่าน USB mic interface เก่า monitoring headphone ได้ยิน round-trip latency ราว 35 ms เปลี่ยนเป็น MOTU M2 + ASIO driver ลดเหลือช่วง 5 ms และการเล่นเดียวกันเปลี่ยนจาก “เล่นไม่ได้” เป็น “ธรรมชาติ” ทันที ปรากฏการณ์ “ออกเสียงที่ไมค์แล้วได้ยินที่หูฟังช้าๆ” ไม่ใช่ bug แต่เป็นหลักฐานจริงว่า round-trip latency มีอยู่ Latency ประกอบด้วยผลรวม 5 ขั้นหลัก เวลาที่ไมค์สะสม sample ที่ sampled แล้วใน input buffer เวลาที่ DAW หรือ communication software ประมวลผล เวลาสะสมผลใน output buffer เวลา DAC แปลงกลับเป็น analog และ เวลาแพร่ทางกายภาพ จากลำโพงถึงหู (ราว 1 ms ต่อ 34 cm) ห้องทูนของ 5 รายการนี้ส่วนใหญ่อยู่ที่ buffer size และ driver model ASIO·WASAPI Exclusive·Core Audio·JACK มี latency ต่ำสุดทั่วไปและข้อจำกัดแพลตฟอร์มต่างกัน บทความนี้สรุปองค์ประกอบ latency, trade-off ของ sample rate·buffer size, ลักษณะตาม driver และ procedure วัด round-trip latency จริง ด้วย loopback cable + test tone + audio software

ภูมิหลังและแนวคิด

ช่วงที่เสียงไมค์เดินทางกลับไปที่ลำโพงผ่านภายในคอมพิวเตอร์ยาวกว่าที่คิด ADC (Analog-to-Digital Converter) sample สัญญาณไมค์ที่ sample rate หนึ่ง (เช่น 48 kHz) แล้วสะสม sample ใน input buffer เมื่อ buffer เต็ม chunk หนึ่ง (เช่น 128 sample) driver ส่งสัญญาณไปยัง software ถึงที่นี่คือ input latency 128 sample / 48 kHz ≈ 2.67 ms เองก็เป็นเวลาที่มีนัยสำคัญ

Software (เช่น DAW, communication app) ใช้การประมวลผล (effect, mix, network prep) กับ buffer ที่รับแล้วเขียนผลใน output buffer chunk ที่เต็มแปลงผ่าน DAC เป็น analog ออกไปที่ลำโพง เวลา output buffer คำนวณคล้ายกัน

สุดท้ายการแพร่ในอากาศ ความเร็วเสียงที่อุณหภูมิห้องราว 343 m/s จึง ราว 1 ms ต่อ 34 cm เพิ่ม headphone แทบไม่มีส่วนนี้ ลำโพง monitor อีกฝั่งห้องเพิ่มหลาย ms นั่งหน้าลำโพง monitor ห่าง 1.7 m คู่หนึ่ง เพิ่ม latency ราว 5 ms จากระยะนั้นเอง

Round-trip latency (RTT) = input buffer + processing + output buffer + DAC/propagation ถ้า sample rate เท่ากัน buffer size เล็กลง latency ลด แต่ CPU ต้องตื่นบ่อยขึ้น โหลดเพิ่ม ถ้ากำหนด buffer เป็นหน่วย sample sample rate เพิ่ม buffer จำนวน sample เดียวกันเวลาสั้นลง แต่ sample rate สูง throughput เพิ่มส่งผล CPU·driver ด้านอื่น

เปรียบเทียบและข้อมูล

เกณฑ์ASIOWASAPI ExclusiveCore AudioJACK
แพลตฟอร์มส่วนใหญ่ WindowsWindows เท่านั้นmacOS เท่านั้นLinux หลัก รองรับหลายแพลตฟอร์ม
latency ต่ำสุดทั่วไปต่ำมาก ช่วงไม่กี่ msต่ำ ช่วงไม่กี่ ms ภายใต้ control เฉพาะต่ำ เสถียร ช่วงไม่กี่ msconfig ได้ต่ำมาก complexity สูง
shared modeต่างตาม driver (มักเป็น exclusive)shared/exclusive เลือกได้ exclusive ต่ำกว่าshared เป็น default แต่ tune ดีrouting matrix เป็นแกน multi-client

ตัวเลข ms ที่แม่นยำแปรผันตาม hardware·driver·OS version เยอะ รับ “1 ms latency” ของข้อความการตลาดเป็นค่าจริงน้อยกว่า ใช้การวัด RTT ในสภาพแวดล้อมของคุณ 1 ครั้งเพื่อตั้ง baseline เป็นจริงกว่า interface ระดับ entry เช่น Focusrite Scarlett 2i2 3rd Gen หรือ MOTU M2 รวมกับ ASIO หรือ Core Audio ลงได้ถึงพื้นที่ ms หลักเดียว ตรงข้าม Windows WASAPI shared path หรือ bypass driver เช่น ASIO4ALL ผลต่างกันมากแม้ hardware เดียวกัน “RTT ของผม” รับเป็นผลของ 3 ตัวแปร hardware·driver·buffer

สถานการณ์จริง

สถานการณ์ 1 — live performance·in-ear monitoring เมื่อ vocal ฟังเสียงตัวเองใน in-ear ขณะร้อง RTT ใหญ่ขึ้นเสียงกลับมาไม่กี่ ms หลัง tempo sense เสีย เป้าหมายในพื้นที่นี้คือ RTT ต่ำกว่า 10 ms เพื่อให้ได้ ลด buffer size สุดท้าย ใช้ low-latency driver เช่น ASIO/Core Audio เมื่อเป็นไปได้ใช้ hardware direct monitoring ของ interface bypass software path MOTU M2 monitor knob ที่ panel หน้าแก้ปัญหานี้ทันที

สถานการณ์ 2 — podcast recording ไม่ใช่กรณีหลายคนใน room เดียวบันทึกพร้อมกัน แต่ละคน record ไมค์ของตัวเอง latency 50–100 ms ยอมรับได้ ในขั้น record latency ต่ำไม่จำเป็น match timeline ใน post-production เอา กลับกัน buffer ใหญ่ช่วย CPU stability บ่อยเป็นบวกต่อคุณภาพ record

สถานการณ์ 3 — video conference browser WebRTC meeting ทั่วไปแสดง latency เฉลี่ย 100–200 ms เพราะรวม network propagation·encoding·decoding ระดับนี้ใกล้ขอบของ conversation ธรรมชาติ รวม latency wireless earphone·Bluetooth conversation เริ่มทับกัน

ความเข้าใจผิดที่พบบ่อย

“Bluetooth latency ใหญ่เสมอ” A2DP classical latency ใหญ่จริง แต่ LE Audio (LC3 codec) หรือ aptX Low Latency ลงพื้นที่ต่ำได้ ความรู้สึกเปลี่ยนจริง “Bluetooth earphone” เดียวกันต่างตาม codec ที่รองรับ แต่สำหรับ monitoring·record wired ยังเป็นตัวเลือกปลอดภัย

“USB audio ดีกว่า analog เสมอ” ถ้า USB interface มี DAC·low-noise preamp·driver ดี สะอาดกว่า analog แต่ USB DAC ราคาถูกมี jitter·noise·driver problem อาจแย่กว่า “USB จึงดี” ไม่ใช่ คุณภาพ component มาก่อน

“sample rate 192 kHz latency ต่ำ” ต่างจากสัญชาตญาณ รักษา buffer หน่วยเวลาเดียวกัน (ms) เพิ่ม sample rate เวลาไม่สั้นลง ถ้าตั้ง buffer เป็นจำนวน sample sample rate เพิ่มเวลา buffer (ms) ลด และ CPU·driver stress เพิ่ม core ของ low-latency ไม่ใช่ sample rate แต่ buffer size และ driver model

เช็กลิสต์

  1. กำหนด RTT เป้าหมาย live performance <10 ms, recording 50–100 ms, conference 100–200 ms ตาม use case
  2. เลือก driver model Windows ASIO หรือ WASAPI Exclusive, macOS Core Audio, Linux JACK/PipeWire shared path default (เช่น MME, shared WASAPI) ส่วนใหญ่ latency ใหญ่
  3. ลด buffer size ทีละขั้นลด RTT ก่อน crackle (dropout) คือขีดล่างจริงของระบบนั้น
  4. ทำ loopback measurement เชื่อมสาย output·input ของ interface เล่น test tone อ่านเวลาต่างระหว่าง waveform ที่รับใน audio editor
  5. sample rate ปรับตามความต้องการของโปรเจ็กต์ video 48 kHz, music 44.1/48 kHz ปกติ 96 kHz ขึ้นไปเมื่อมีเหตุผลชัดเท่านั้น
  6. ตรวจ monitoring path แทน software monitoring ของ DAW ใช้ interface direct monitoring ทำ RTT เกือบเป็น 0 ได้

เครื่องมือที่เกี่ยวข้อง

เครื่องวัด audio latency ของ Patrache Studio ออกแบบให้ประเมิน round-trip latency ของ input·output path ในเบราว์เซอร์คร่าวๆ เข้าใจสภาพระบบปัจจุบันโดยไม่ต้องซื้อ hardware หากดู latency รวมของ input device ด้วย อ่าน คีย์บอร์ด N-Key Rollover (NKRO) และสำหรับ A/V sync ใน video call อ้างอิง latency ฝั่งกล้องใน การวินิจฉัยเว็บแคม จะช่วยวินิจฉัยอย่างสมดุล

อ้างอิง

เครื่องมือที่เกี่ยวข้อง

diagno.patrache.studio/audio/latency/