เรามาเริ่มจาก bit กันเลยดีกว่า
bit คืออะไร:
bit คือสถานะว่า มี กับ ไม่มี เทียบได้กับ 1(มี), 0(ไม่มี)
ที่เก็บข้อมูล:
มีหลากหลายรูปแบบ มีทั้งเก็บได้ชั่วคราวแบตหมดไฟฟ้าไม่เลี้ยงข้อมูลหาย และแบบเก็บได้ถาวรไม่ต้องมีไฟฟ้าเลี้ยง เช่น Ram, Memory, Hard disk เอาเป็นว่าไม่ลงรายละเอียดเพราะพอรู้จักกันอยู่แล้ว
แต่ที่อยากบอกคือ ที่เก็บข้อมูลทุกอันประกอบไปด้วย กล่องเรียงต่อกันยาวมากกๆๆๆๆๆ แต่ละกล่องนี้เก็บของได้ 1 ชิ้นเท่านั้น
- ถ้ากล่องนั้นมีของเก็บไว้แล้ว จะเรียกว่า มี ในทาง digital เรียกว่า 1
- ถ้ากล่องนั้นไม่มีของเก็บไว้อยู่ จะเรียกว่า ไม่มี ในทาง digital เรียกว่า 0
กล่องแต่ละใบเหล่านั้นเรียกว่า "bit"
ทีนี้เนื่องจากที่เก็บข้อมูลมีขนาดใหญ่มากทำให้จำนวนกล่องนั้นมีมากมาย การบริหารจัดการกล่องทีละใบจึงเป็นเรื่อง น่าเบื่อ ชิหาย
เค้าเลยเอากล่องมาเรียงต่อกัน 8 กล่อง
[] [] [] [] [] [] [] []
เราสามารถเอาของมาใส่ได้หลากหลายรูปแบบ เช่น
[0] [0] [0] [0] [0] [0] [0] [0] => ว่างทุกกล่อง
[1] [1] [1] [1] [1] [1] [1] [1] => เต็มทุกกล่อง
[1] [1] [1] [1] [0] [0] [0] [0] => เต็มครึ่งนึง
[0] [0] [0] [0] [1] [1] [1] [1] => ว่างครึ่งนึง
.
.
.
รวมทั้งหมดแล้ว เก็บได้ 256 แบบ (มันคือ 2 ยกกำลัง 8 ถ้าอยากจะรู้อ่ะนะ)
กระนั้นเลย เราเอาแต่ละรูปแบบมาแทนตัวอักษรดีกว่า เรียกกันว่า ASCII Table
โดยแทน กล่อง 8 กล่อง (8bit) ด้วยตัวอักษร 1 ตัว เช่น
{ อ่านตัวเลขจากขวาไปซ้าย <-- เหมือนที่เราอ่านเลข 21 ขวาสุดมีค่าน้อยสุด }
ตัวอักษร @ แทนด้วยกล่อง |<-- [0][1][0][0] [0][0][0][0] <--| ตีเป็นเลขฐาน8: 0x40 ซึ่งมีค่า = 64
ตัวอักษร A แทนด้วยกล่อง |<-- [0][1][0][0] [0][0][0][1] <--| ตีเป็นเลขฐาน8: 0x41 ซึ่งมีค่า = 65
ตัวอักษร B แทนด้วยกล่อง |<-- [0][1][0][0] [0][0][1][0] <--| ตีเป็นเลขฐาน8: 0x42 ซึ่งมีค่า = 66
.
.
.
นั่นคือ ตัวอักษร 1 ตัว แทน 8bit เรียกว่า 1 "char" ย่อมาจาก character
อ้าว แล้ว เพลง, audio data ของเรามัน 16bit?
เราก็ใช้ 2 ตัวสิ AA AB BB ...
คู่นึงก็ได้แล้ว 16bit
แล้วถ้าอยากได้ 24bit ล่ะ?
ก็แถมให้ไปอีกตัวเป็นไง 8x3 = 24
AAA AAB AAC ABC ....
ซึ่ง 1 ชุด ไม่ว่าจะเป็นคู่ หรือเป็น 3 ตัว เราเรียกว่า "word"
แล้วเรามาเรียนรู้เรื่อง bit, char, word กันทำไม?
ก็เพราะข้อมูลที่วิ่งส่งผ่านสาย USB มันส่งมาเป็น word ยังไงล่ะ
เพราะงั้นเสียงที่เราได้ยินผ่าน DAC มันมาจากตัวอักษร AB CD EF GH ... พวกนี้แหละ
ต่อไปเข้าเรื่อง USB กันต่อ
USB spec and System Design:
เอาเนื้อๆนะ
USB ส่งข้อมูลผ่านสิ่งที่เรียกว่าท่อ(pipe) แน่นอนว่าไอ้ท่อนี้มันไม่มีจริงหรอก เป็นแค่สิ่งสมมติ เพื่อให้ต้นทางกับปลายทางเข้าใจตรงกัน
ทีนี้ไอ้ท่อเนีีย มันก็มีประเภทของมันอยู่คือ
1. stream
2. message
message: เป็นการสื่อสารสองทาง ทั้งไปและกลับ มักจะใช้สำหรับการส่งคำสั่ง ควบคุม เพื่อให้ต้นทาง (PC, Mac, Android, iOS) สั่งงานไปที่ปลายทางได้ โดยจะส่งเป็นคำสั่งสั้นๆและให้ปลายทางตอบรับเสมอ เหมือนเราสั่งน้องไปซื้อกาแฟ ถ้ามันนิ่งก็ต้อง เบิดกระโหลก 1 ทีพร้อมทวนคำสั่งอีกครั้ง จนกว่ามันจะบอกว่า "ได้ครับพี่"
stream: เป็นการสื่อสาร "ทางเดียว" ส่งอย่างเดียว ไอ้ตัวรับมึงจะรับถูกรับผิดกรูไม่สน กรุส่งให้แล้วนะ
จากประเภทของท่อ เราแบ่งประเภทการรับส่ง หรือเรียกว่า end point ออกได้อีกเป็น
1. Control transfers [message]
2. Interrupt transfers [message]
3. Isochronous transfers [stream]
4. Bulk transfers [stream]
อันที่เราคุ้นเคยที่สุด และเผลอคิดไปว่า นี่คือโลกทั้งหมดของ USB แล้ว คือ 4.Bulk transfers เพราะว่าเวลาเรา transfer file ไปใส่ใน external hardisk, flash drive เราใช้ Bulk transfers
ซึ่งไม่ว่าเรา copy กี่ครั้ง ไฟล์ที่ได้ก็เหมือนต้นฉบับ copy กลับมาเทียบกัน ก็ตรงกันเป๊ะ
สาเหตุก็คือว่า Bulk transfers มีกระบวนการส่งที่ซับซ้อน และมี CRC16 แปะติดไปกับ package ทุกอันเพื่อให้ปลายทางตรวจสอบเอาเองว่า ข้อมูลที่ได้ถูกต้องหรือไม่
ซึ่งถ้าไม่ถูก ก็ทำการ ส่งคำว่า STALL ตอบกลับไป หรือถ้าตัวรับยังไม่พร้อมก็จะส่งคำว่า NAK กลับไป
(ถ้าใครเคยทำ Hardware interface ผ่าน port serial/lp/usb จะเข้าใจกระบวนการ ACK, NAK เป็นอย่างดี)
**จริงๆแล้ว audio system ควรใช้การเชื่อมต่อประเภทนี้เนอะ**
ดูได้ตามในรูป
แต่ USB specification ที่ใช้สำหรับการส่งข้อมูล ภาพและเสียง แบบ digital กำหนดให้ใช้ 3.Isochronous transfers ครับ
นั่นทำให้ OS ทั้งหลาย Window, macOS, Android, iOS จะรู้วิธีส่งข้อมูลเสียงได้ ก็ต้องส่งผ่านวิธีนี้เท่านั้น
ตัว usb chip controller ทั้งหลายก็ตอบรับกับมาตรฐานนี้ด้วยเช่นกัน
เช่น spec ของ PCM2707C: Stereo Audio DAC with Full Speed USB Interface
On-Chip USB Interface:
- No Dedicated Device Driver Needed
- Full-Speed Transceivers
- Fully Compliant With USB 2.0 Specification
- USB 1.1 Descriptors With USB Audio
- Class Support
- Certified by USB-IF
- Partially Programmable Descriptors
**- Adaptive Isochronous Transfer for Playback
- Bus-Powered or Self-Powered Operation
นั่นทำให้ เราหลีกนี้ USB end point แบบ Isochronous transfers ไม่พ้น
ถ้างั้นเรามาดู Isochronous transfers กันให้ชัดๆ
Isochronous transfers:
- Guaranteed access to USB bandwidth.
- Bounded latency.
- Stream Pipe - Unidirectional
- Error detection via CRC, but no retry or guarantee of delivery. T_T
- Full & high speed modes only.
- No data toggling.
- 8,000 transfers per second
ดูตามรูป
usb ช่องนี้ รับประกันในเรื่อง อัตราการส่งข้อมูล และให้ priority ในการจัดสรรการทำงานของ CPU ใน แต่ OS (Window, macOS, Android, iOS) สูงกว่างานอื่น
มีการตรวจสอบความถูกต้อง ผ่าน CRC ปลายทางสามารถรู้ได้ว่าข้อมูลผิด แต่ ไม่มีการส่งข้อมูลซ้ำ ผิดแล้วผิดเลย เพราะว่าไปตกลงกันเรื่อง Time Domain แล้ว ไม่มีเวลามาส่งซ้ำให้หรอกนะ หุหุ
อืม เหมือนจะดีเนอะ แล้ว อัตราการส่งข้อมูล เนี่ยเอาไว้ทำอะไร ทำไมต้องรับประกัน
เอาล่ะ งั้นถ้าต้องการส่งข้อมูลเพลงที่ rip มาจาก CD เป็น 16bit 44.1 kHz
16bit แสดงว่าต้องส่งครั้งละ 2 char แล้วต้องส่งกี่ครั้ง?
44.1kHz = 44,100Hz ซึ่งคำว่า Hz ย่อมาจาก Hertz ความหมายคือ รอบต่อวินาที
2 channel แสดงว่า data x 2
44,100 x 2 channel x 2 byte = 176,400
usb ส่งข้อมูลได้ 8000 ครั้งต่อ วินาที แต่ละครั้งจะส่งข้อมูลเป็น
176,400 / 8,000 = 22.05 byte
บางครั้ง 24 byte บางครั้ง 20 byte เฉลี่ยแล้วก็จะได้ 22.05 byte
ทั้งหมด 8000 ครั้งต่อวินาที ความเร็ว bandwidth ห้ามตก ห้ามมีใครแทรกแซง
อันนี้แหละที่ต้องการ อัตราการส่งข้อมูล ที่คงที่
ทีนี้ก็มาถึงปัญหาข้อต่อไป นั่นคือ Time Domain
สมมติสร้าง data คิวขึ้นมา 1 คิว เป็นแบบ FIFO(first in, first out)
เข้า---------------------------------ออก
--> KK JJ II HH GG FF EE DD CC BB AA -->
ข้อมูลจาก USB buffer จะถูกป้อนเข้าไปที่ Dac ได้ จะต้องประกอบไปด้วย 2 ส่วน คือ data stream, และ sample clock โดย sample clock จะส่งผ่าน endpoint อีกตัวคือ Interrupt transfers
โดยจะส่งมาเหมือนสัญญาณ ว่า ดึง...ดึง...ดึง...ดึง...
จังหวะการดึงนั้นเองก็คือ usb clock signal ที่รับมาจากต้นทาง เพื่อดึง data จาก data stream มาใส่ให้ dac
ซึ่งแน่นอน ต้นทางกับปลายทางต้องตกลงกันก่อน ว่าจะดึงข้อมูลขึ้นมาทีละกี่ byte(กี่ bit), sample rate อยู่ที่เท่าไหร่
ทีนี้ถ้าต่างคน ต่างก็เป๊ะเรื่องเวลา มันก็ไม่มีปัญหา แต่เท่าที่รู้ Computer CPU หรือ Mobile CPU ไม่ได้ทำงานอย่างเดียว แล้วสัญญาณนาฬิกาของ CPU พวกนี้ไม่ได้เป็นระบบตรงเป๊ะๆ
แต่เป็นระบบตามใจฉัน
ถ้า cpu บอกว่า Tick ทุกคนก็ต้องพูดตามว่า Tick
ถ้า cpu บอกว่า Tock ทุกคนก็ต้องพูดตามว่า Tock
ทีนี้ลองแทนค่าเล่นๆดู
ถ้า เมีย บอกว่า CHANEL สามีก็ต้องพูดตามว่า CHANEL
ถ้า เมีย บอกว่า หลุยวิตอง สามีก็ต้องพูดตามว่า หลุยวิตอง
เช่นนี้ถึงจะอยู่กันได้ ด้วยความเข้าใจ T_T(หรือเศร้าใจ)
Tick, Tock คือการกำหนดสัญญานนาฬิกา ที่มาจาก CPU, hardware ทุกตัวต้องอิงจากสัญญาณที่มาจาก cpu ไม่งั้นมันจะ sync กันไม่ได้ ทำงานร่วมกันไม่ได้
เมื่อ cpu ทำงานตามใจฉัน สัญญาณนาฬิกา ที่ส่งผ่านมาให้ ของ usb จึงออกมาเป็นแบบ เกือบตรง และตามใจ cpu
ทำให้ dac ปลายทางนั้นมีปัญหามาก ซึ่งจะแสดงออกมาในรูปของ Jitter
ต่อให้ข้อมูลได้ครบ แต่ timing ผิดเพี้ยน เมื่อ dac ทำการแปลงออกมาเป็น analog signal จึงเกิดการซ้อนทับกัน ของสัญญาณanalog ทำให้ ได้คลื่นผิดเพี้ยนไปจากต้นฉบับที่บันทึกอยู่ใน file
ชิบหาย ถ้างั้นทำไงดีให้เสียงมันดีขึ้นล่ะ
บางเจ้าก็บอกว่า เค้ามี
Adaptive Isochronous Transfer แปลความว่า ตกลงเพิ่ม delay ระหว่างผู้ส่งและผู้รับอีกนิดหน่อย เพื่อให้จังหวะการรับส่ง ไม่เครียดมากนัก
แต่ก็เพิ่มประสิทธิภาพเพิ่มขึ้นได้แค่นิดหน่อย ขึ้นอยู่กับต้นทางอยู่ดีว่า มีความสามารถในการจัดการ Timing ได้ดีแค่ไหน
มันก็เลยมีผู้ผลิตชิบอย่าง Xmos ออกมาบอกว่า ของเค้าเป็น USB แบบ Asynchronous นะ อู้ว
คนไม่รู้เรื่องทางเทคนิคก็จิ้นไปว่า มันคงเอา data มาเก็บไว้ก่อน เพื่อตรวจสอบความถูกต้องแล้วค่อยส่งต่อให้ dac ทำงานต่อ
แต่ด้วยเหตุผลทาง usb specification ด้านบน ที่นำเสนอให้ฟังไปแล้วนั้น มันไม่ใช่ครับ Data loss ได้อยู่ดีเพราะส่งไปทาง USB end point Isochronous transfers อันเดิม
แล้วอะไรที่เป็น Asynchronous ล่ะ?
มันคือ Time Domain ครับ
นั่นคือตอนจังหวะดึง จะไม่ได้ใช้ของ usb ที่ส่งมาทาง Interrupt แต่ใช้แค่เป็นการ sync เป็นช่วงๆ
แล้วก็ใช้ Internal clock ในการดึงข้อมูลจาก data stream เข้าไปที่ DAC
มักจะพบได้ใน บรรดา Dac แพงๆ หรือไม่แพงแต่เสียงดีคุ้มราคาทั้งหลาย
เพราะสามารถแก้ปัญหา เรื่อง Time Domain ได้ ส่วนจะเสียงดีขึ้นแค่ไหนนั้น ขึ้นอยู่กับ Internal clock และ chip ที่ประมวลผล ของตัว DAC เองแล้ว
ซึ่งบางกรณี ก็นำมาสู่เสียงที่แย่ลงได้เช่นกัน หากออกแบบไม่ดี หรือเทียบกับต้นทางที่มี clock ที่ดีอยู่แล้ว
ทั้งหมดที่นำเสนอมานั้น เป็นการพิสูจน์ว่าเชิงทฤษฎีและ specification ว่า
:: สาย USB แต่ละเส้นที่จะเอามาใช้สำหรับ Audio Data นั้น จะให้เสียงแตกต่างกัน จากความสามารถในการรักษาข้อมูล digital ระหว่างทาง
ส่วน Time Domain นั้น ขึ้นอยู่ กับ DAC เทียบกับ ต้นทาง ว่าใครจะ control timing ได้ดีกว่ากัน
ทีนี้ก็พูดถึง spdif บ้าง
spdif:
เป็นการส่งข้อมูล digital โดย ทำการส่งเป็น block แต่ละ block แบ่งออกเป็น หลายๆเฟรม ในframe มี sub frame ในแต่ละsubเฟรม จะแบ่งเป็น header, aux data, data, flags...
ตามรูป
ส่วนสำคัญคือ data โดยจะถูกเข้ารหัสข้อมูล รวมกับ time domain และส่งมาพร้อมๆกันเลย
ปลายทางก็ทำการถอดรหัส ก็จะได้ audio data พร้อมทั้ง time data คู่กัน
แต่ก็มีแต่ data ยังไม่มี สัญญาณ clock จริง
spdif จะเชื่อมสัญญาณ clock จากตัวเดียวกันทั้งระบบ เรียกว่า master clock ที่เหลือเป็น slave clock
ขึ้นกับว่าใครเป็นต้นทาง ถึงมี clock ในตัวเอง ถ้าไม่ได้เป็น master clock ก็ไม่ได้ใช้ internal clock เช่นกัน
ดังนั้น spdif จะให้เสียงดีได้ นอกจากดูสายแล้ว ก็ต้องดู clock ต้นทางที่จะมาเป็น master clock ด้วยเช่นกัน
เพราะงั้น ถ้าจะเลือกระหว่าสาย usb/coaxial ให้ดู usb ก่อนว่าเป็น Asynchronous รึเปล่า และต่อให้เป็น ให้ดูต้นทางก่อนว่า clock ที่ใช้นั้นดีกว่าปลายทางหรือเปล่า
PS.
mojo มีความสามารถพิเศษก็คือ re-clock ทั้ง usb/coaxial/TOSLink ไม่ว่าจะต่อทางไหน ก็ได้ผลใกล้เคียงกัน จากนั้นค่อยดูวัสดุและราคาของสาย usb/coaxial ที่กำลัง compare
และอย่าลืมว่า dap/player บางตัวไม่สามารถส่ง hi-res ผ่าน coaxial ได้สูงนัก โดยเฉพาะ DSD
