Tech

โหลดข้อมูล A-GPS ลงกล้อง

posted on 18 Apr 2012 18:48 by ipats in Tech directory Lifestyle, Tech, Knowledge
สวัสดีฮะ
 
อย่างที่บางคนอาจจะทราบแล้วว่า (ทราบได้ยังไง??) ผมได้ไปถอยกล้องมาใหม่ตัวนึง
มันคือ Sony SLT-A65 นั่นเอง 
 
ซึ่งไอ้กล้องตัวเนี่ย มันมีความสามารถอย่างนึงที่น่าสนใจ คือ มี GPS ในตัว
 
พูดง่ายๆ ก็คือ เวลาถ่ายรูป มันจะแท็กสถานที่ลงไปในรูปด้วย ว่าเราถ่ายจากที่ไหน
ดูน่าสนใจ เหมือนกล้องในโทรศัพท์มือถือเลย
 
แต่จุดที่ต่างกันก็คือ GPS บนมือถือ มันสามารถต่ออินเทอร์เน็ตเพื่อโหลดข้อมูลดาวเทียมมาได้ตลอดเวลา ทำให้มันสามารถหาพิกัดของเราได้อย่างรวดเร็ว (ที่เราเรียกกันว่า A-GPS นั่นแล คือมันต้องโหลดข้อมูล "Assisted" มาจากเน็ต)
 
ทีนี้ พอเป็นกล้อง มันต่อเน็ตไม่ได้ แล้วมันจะโหลดข้อมูลนี้มาจากไหน? คำตอบอยู่ที่ความโชคดีที่ "Assisted Data" มันมีอายุยาวนาน โหลดทีนึงใช้ได้ประมาณหนึ่งเดือน เพราะฉะนั้น เราก็สามารถใช้คอมพิวเตอร์โหลดข้อมูลนี้มาด้วยโปรแกรมที่มากับกล้อง แล้วโปรแกรมมันก็จะโหลดข้อมูลลงกล้องเพื่อให้มันใช้งาน "Assisted Data" ได้ไปหนึ่งเดือน, ข้อมูลหมดอายุเมื่อไหร่ ก็เอามาต่อคอมใหม่ โหลดใหม่ (ถ้าไม่มีข้อมูลช่วย มันจะใช้เวลาล็อกตำแหน่ง 5-15 นาทีเชียวนะ..​ แต่ถ้ามีข้อมูลนี้ช่วย จะเหลือเพียงไม่ถึงนาที!)
 
แต่!! มันมีปัญหาขึ้นมาอีกปัญหานึง (ไม่งั้นผมคงไม่ได้เขียนเอ็นทรีนี้)
 
ไอ้กล้องตัวเนี่ย มันเป็นของอารยธรรมโซนี่ ซึ่งโปรแกรมที่มันแถมมา (ชื่อว่า PMB - Picture Motion Browser) มัน "เสือก" มีแต่เวอร์ชั่นบนวินโดวส์ มันไม่สามารถเอามาใช้กับ "แมคบุ๊ค" ของท่านศาสดาได้ Y-Y
 
ความเศร้าบังเกิด..
 
แต่อย่ากระนั้นเลย บนโลกนี้คงไม่ได้มีคนรักอารยธรรมและบูชาศาสดาไปพร้อมๆ กันแค่เราคนเดียวแน่ๆ
 
สุดท้าย ผมก็ไปเจอลิงค์นี้ http://blog.brixandersen.dk/2010/04/02/downloading-sony-gps-assist-data-using-perl/
 
เค้าอธิบายว่า เพียงแค่เราไปโหลดไฟล์ assistme.dat จากเว็บของโซนี่
แล้วเอามาใส่ในการ์ดที่พาธ /Private/SONY/GPS/ , เสร็จแล้ว ยัดการ์ดลงกล้อง เปิดกล้องขึ้นมา
 
แจ่มแจ่แดมแจ่มว้าววว~~ กล้องก็จะมีข้อมูล assisted เอาไว้ช่วยล็อกตำแหน่งดาวเทียมได้แล้ว เย้~~~
 
 
ปล. กล้องที่มี GPS แต่ละตัว ไม่ได้รองรับ A-GPS ทุกตัวเน้อ มันมีแค่บางตัว, ผมเคยใช้ Lumix TZ-10 มันดีตรงที่มีชื่อสถานที่บอกด้วยในกล้องเลย ไม่ต้องรอโหลดรูปเข้าคอม, แต่ข้อเสียคือ ล็อกสัญญาณดาวเทียมนานมาก Y-Y
 
ปล2. Assisted Data ที่โหลดมา ก็คือข้อมูลเกี่ยวกับวงโคจรของดาวเทียมนั่นเอง คือระบบ GPS เนี่ย มันจะหาตำแหน่งเราจากการวัดระยะห่างกับตำแหน่งดาวเทียม ซึ่งถ้าเราไม่รู้ตำแหน่งดาวเทียม มันก็ต้องเสียเวลารับข้อมูลจากดาวเทียมโดยตรงว่ามันอยู่ไหน ซึ่งมันรับได้ช้ามาก ประมาณ..​เอ่อ.. 50 บิตต่อวินาที ... ใช่ฮะ ไม่ผิดฮะ ความเร็วแค่ 50 บิตต่อวินาที!!
 
 

SSD vs HDD ภาคจบ

posted on 06 Feb 2011 12:12 by ipats in Tech
สวัสดีครับ

ภาคจบ.. ฮ่าๆ

ตอนแรกก็ว่าจะเฉยๆ จบๆ ไป แต่นะ.. มันอดไม่ได้
เห็นคนเข้าใจอะไรผิดๆ เราก็อยากช่วยแก้ให้ถูก

ก่อนอื่น ขอย้ำประเด็นของผมก่อน

เริ่มจาก "SSD เสียงแห้ง"
ซึ่งมีคนเคลมว่าเสียงจากการเล่นเพลงบน SSD และ HDD ต่างกัน ด้วย Storage Latency

ข้อสังเกต
1. ตอนแรกที่บอกว่า "SSD เสียงแห้ง" ผมเข้าใจไปเองว่า มันหมายถึง SSD มีผลกระทบในแง่ลบ แต่ไปๆ มาๆ "เค้าว่า" latency ใน hdd ทำให้เสียงเพี้ยนได้.. เอ ไปๆ มาๆ ผมเริ่มไม่แน่ใจแล้วว่า มันดี หรือมันแย่กันแน่ แต่สรุปรวมๆ เค้าว่ามันต่างกันแหละน่า

2. ไอ้ที่ต่างกันเนี่ย เค้าบอกว่าเกิดมาจาก Access Time ของ Storage Device (ซึ่งถ้าใช้ NAS ก็คงจะเสียงห่วยไปสุดๆ เลยทีเดียว)

3. ประเด็นเรื่องเสียงต่าง/ไม่ต่าง อันนี้ผมบอกได้แน่นอนว่ามัน "ควร" ต่างกันแน่นอน เพราะ DAC มันทำงานได้ไม่เที่ยงตรง.. ซึ่งเป็นเพราะมันมีภาค Analog ซึ่งที่ต่างก็เพราะปัจจัยหลายอย่าง เช่น Clock Generator ความถี่ไม่นิ่ง, มีการรบกวนกันของกระแสไฟฟ้า, ไฟไม่นิ่ง ฯลฯ แต่ไม่ใช่ "HDD ช้า" อย่างที่ "เค้า" อ้าง (เพราะงั้น เสียงแห้ง ไม่แห้ง อะไรนี่ผมไม่สน ผมสนที่เค้าเคลมเหตุผล)

** จากข้อ 3, มันเลยสามารถสรุปลงไปได้ว่าทำ blind test ไปก็ไม่ใช่ว่าจะได้ข้อสรุปครับ
เพราะถ้าหูของ "พวกเค้า" ไวมากจริงๆ noise เพียงเล็กน้อยก็มีผลแล้ว อุณหภูมิห้องเปลี่ยน ก็มีผลกับเสียง เวลาฟัง ขยับหัวเล็กน้อย ก็เกิด doppler effect แล้ว ระยะต่างๆ ก็มีผลหมด (นั่งห่างจากลำโพง 1 เมตร ก็เกิด latency ไป 3ms แล้วครับ, สงสัยว่าจะมาเอาอะไรกับ 1ms ของ buffer), เอ่อ.. หรือไม่.. การที่เราหายใจมากๆ ก็ทำให้เสียงเพี้ยนได้นะครับ (CO2 หนักกว่า O2!! ยิ่งหายใจ เสียงยิ่งเพี้ยน.. โอ้ววม่ายยยย~)

เอ็นทรีนี้ผมคงไม่อธิบายส่วนที่พูดถึงไปแล้ว แต่ขอพูดแย้ง และอธิบายสิ่งที่เค้าอ้างมาแล้วกัน

1. XXHighEnd
อันดับแรก วันแรกๆ นั้น เค้าเอาลิงค์มาให้ผมดู บอกว่าเนี่ย เปรียบเทียบการเซ็ต buffer latency ค่าต่างๆ แล้ว เสียงไม่เหมือนกัน มีกราฟประกอบ ให้ไปอ่านดู เป็นข้อพิสูจน์ แล้วก็บลัฟต่อ

ด้วยว่า มันไม่ใช่เรื่องที่จะเข้าใจได้ง่ายๆ หรอก ต้องใช้เวลาเป็นเดือนๆ บลาๆๆ

โอเค จะอธิบายให้เค้าเข้าใจ
1.1 "เค้า" บอกว่า กราฟเนี่ย แสดงถึง bit stream ที่ไปยัง soundcard ที่มันไม่เหมือนกันเพราะปรับ latency (ซึ่งก็เป็นการเอา storage latency มามั่วกับ buffer latency อีกเช่นเดิม) เพราะฉะนั้น computer มันผิดพลาดได้ ไม่ใช่ bit-perfect!

ดูกราฟ: http://www.computeraudiophile.com/content/Why-does-computer-matter#comment-61713
ตอบ:
ในลิงค์ที่เค้าส่งมา มีเขียนชัดเจนว่า "This is an analogue take from a DAC I own" แปลว่า.. ไอ้กราฟที่เค้าได้มาเนี่ย มันคือเอาท์พุตที่เป็นอนาล็อกที่ออกมาจาก DAC คร้าบบบ.. ไม่ใช่ข้อมูล Digital ที่ส่งไป DAC

แถมเค้าก็ไม่บอกอีกว่าเอาข้อมูลอนาล็อกนี้กลับมายังไง ซึ่งผมค่อนข้างแน่ใจว่า ก็อัดเอาจาก Line-in นี่แหละ ซึ่งใครๆ ก็ทราบดีกว่า การเล่นเพลง ถึงแม้จะมี parameter เหมือนกัน สมบูรณ์ทุกอย่าง แต่ผ่าน DAC แล้วย้อนมา ADC อีกรอบเนี่ย ทำยังไงมันก็ไม่เหมือนเดิมครับ

1.2 นอกจากนี้ ไอ้คนที่เอากราฟมาเดโมเนี่ย เค้าเป็นคนที่พัฒนาโปรแกรมที่ชื่อว่า XXHighEnd ซึ่งเป็นโปรแกรมฟังเพลง ที่เค้าเคลมว่าดีมาก โดยวิธีทำกราฟของเค้าบอกว่าเปลี่ยนค่า parameter Q1 ในโปรแกรมของเค้าเป็นค่าต่างๆ แล้วเอามาเทียบ.. แต่ขอหน่อยเถอะ ไอ้ค่า Q1 นี่มันคืออะไรครับ, เค้าอ้างว่าเป็นการปรับ latency อะไรซักอย่าง แต่ผมไม่สามารถหา reference ได้เลย จะโหลดโปรแกรมมาลองใช้ ก็เกิดเรื่องอีก เพราะมันรันไม่ขึ้น (สงสัยโดนพิษ 64-bit เหอๆ)

สุดท้าย ผมก็ต้องไปพึ่ง forum ต่างๆ แล้วก็ได้มาว่า..
"XXHighEnd" - what is this player?
http://www.hydrogenaudio.org/forums/index.php?showtopic=68514

XXHighEnd player for Vista and XP better than foobar?
http://www.head-fi.org/forum/thread/246554/xxhighend-player-for-vista-and-xp-better-than-foobar

เอาไปอ่านแค่สองอันพอ
ถ้าขี้เกียจอ่าน จะสรุปให้ฟังว่า

คนใน forum หลายคนให้ความเห็นว่า XXHighEnd มันเป็นโปรแกรมอะไรก็ไม่รู้ ที่คนพัฒนาไม่สามารถอธิบายอะไรได้จริงๆ จังๆ เป็น concrete เลย มีการอ้างว่าโปรแกรมนี้ ส่งเสียงเป็น bit-perfect แต่สามารถปรับแต่งค่าได้, ปรับแล้วมันจะ perfect ได้อย่างไร ก็ไม่มีคำตอบ มีแต่อ้างเรื่อง jitter, ซึ่งก็มีคนลงความเห็น (ที่มันเป็นจริง) ว่า jitter มันไม่มี, เอะอะๆ จะมา jitter หน่ะ มันโลกอนาล็อครุ่นคุณปู่คร้าบบบ

รายละเอียดลองอ่านกันดูในลิงค์ สนุกมาก ดราม่าสุดๆ แรงกันขนาดที่ว่า มีคนกล่าวหาตาปีเตอร์ (คนที่พัฒนา) ว่า เชียนโปรแกรมหลอกๆ มา เพ้อให้ดูดี แล้วเก็บตังค่าโปรแกรม (70 ยูโรเชียวนะครับ, โปรแกรมยังเบต้าอยู่ด้วย บั๊กก็เยอะ หน้าตาก็ห่วย)

สุดท้าย ได้ข้อสรุปว่าโปรแกรมนี้ คนพัฒนาไม่น่าเชื่อถือ การทำงานของโปรแกรมไม่เคลียร์ แถมมีคนไม่ยอมรับอีกมาก

เพราะฉะนั้นประเด็นกราฟซึ่งเค้ามั่นใจหนักหนาว่าเป็นหลักฐานที่ดีมาก "ตกไป" เป็นฉะนี้นั่นเอง

2. Bit-Perfect
อันนี้ขออธิบายไว้เล็กน้อย คำนี้ ในคอนเท็กนี้หมายถึงว่า โปรแกรมเล่นเพลง สามารถถ่ายทอดทุกๆ บิต จากไฟล์เพลง ไปยัง Soundcard ได้ครบทุกบิต และเหมือนเดิมทุกประการ จริงๆ เหมือนเป็นเรื่องง่าย แต่ก็ยากอยู่ทีเดียว ไม่ใช่เพราะว่า HDD อ่านไม่เร็วพอ แต่เพราะ

2.1 Multimedia Subsystem ของ OS (เช่น directsound) มันปรับเสียงให้เราเอง อย่างเช่นใน Windows เราจะเห็นได้ว่า หลายๆ โปรแกรมสามารถส่งเสียงได้พร้อมกัน เพราะว่ามันจะมี Mixer เป็นตัวรวมเสียงให้ และจัดการเรื่องต่างๆ (เช่นปรับ sample rate/resolution ให้เหมาะสม) การปรับ volume ก็ทำให้มีการแก้ไขข้อมูลเกิดขึ้น มันเลยเกิดมีวิธีพิสดารขึ้นมา คือการข้ามตัว subsystem ตรงนี้ไป แล้วไปติดต่อกับ driver (เกือบจะ)โดยตรงแทน (ที่หลายคนรู้จักในนาม ASIO/WASAPI)

2.2 Media Player มันมีลูกเล่น เช่น DSP ซึ่งถ้าเราต้องการ bit-perfect จริงๆ ต้องปิดการทำงานตรงนี้ทุกอย่าง รวมถึง EQ และแน่นอน volume control ด้วย!!

ผมว่า.. ถ้าทำขนาดนี้ คงต้อง output เสียงจากคอมเป็น digital แล้วไปผ่าน AVR เมพๆ อะไรทำนองนั้นอีกทีจะดีว่า :D

3. Thread Priority
เรื่องนี้ดูท่าจะเยอะ สรุปสั้นๆ หน่อย ว่า thread priority มีผลเมื่อ
3.1 ใช้ soundcard onboard ที่จำเป็นต้องทำ Mixing/DSP ที่ CPU (ถ้า CPU ไม่ว่าง ก็มีผล จริงไหม)
3.2 ใช้ Software DSP ที่หนักมากๆ (ถ้า CPU ทำงานไม่ทัน ก็เจ๊งคร้าบบ)
3.3 Codec ซับซ้อน, bitrate สูงเกินไป decode ไม่ทัน (ถ้าเป็นการเล่นวิดิโอ ก็เทียบได้กับการเอา Atom ไปเล่น H.264 1080p โดยไม่มีการ์ดจอ! มันเล่นได้ก็เมพแล้วคร้าบบ~~)
3.4 I/O เต็ม! อันนี้ไม่ใช่ว่าเป็นประเด็น HDD/SSD นะครับ I/O ที่ว่านี้ คือ System Bus ทั้งหมดมันเต็ม เกิดคอขวดขึ้น, ตอนนี้นึก case ไม่ออก แต่เอาเป็นว่า ถ้าฟังเพลงไป แล้วมีการใช้ app ที่รันหนักๆ (เช่น BOINC + VMWare) ก็เตรียมฟังเพลงกระตุกได้เลย (เพลงกระตุกนะครับ ไม่ใช้เพลงเสียงคุณภาพแย่ลง) + แถมอาจจะได้ BSoD เป็นของแถมด้วยนะ

เอ่อ.. นึกออกแค่นี้...

สรุปว่าในงาน Pro Audio ซึ่งมีทั้ง synthesis, mixing, dsp มันเลยต้องการ priority สูงๆ ไงครับ แต่ถ้าเอามาฟังเพลงเนี่ย มันไม่จำเป็นเลย!

4. CD Rip
ใครว่าอ่านข้อมูลจาก CD แล้วได้เหมือนเดิมเสมอ?? เกือบจริง แต่ไม่ทั้งหมด
เพราะถ้า CD มันเสีย มันก็อ่านไม่ได้จริงไหม!! /ผ่าง~~

ปูพื้นฐานก่อน การเก็บข้อมูลใน CD เนี่ย ไม่ได้เก็บแบบแผ่นเสียงนะครับ ที่เอาเข็มลากๆ แล้วมีเสียง
แต่ในแผ่น CD จะใช้การ "ขุดหลุม" เพื่อให้เป็นร่อง ยาวบ้าง สั้นบ้าง (หลุมยาว ก็คือหลุมสั้นที่ติดกันนั่นแหละ)
ทีนี้ พอเข้าเครื่องอ่าน เลเซอร์ก็จะยิงไปที่แผ่น แล้วดูแสงสะท้อนว่ามันสะท้อนที่ปากหลุม หรือก้นหลุม

ถัดมา CD-Audio กับ CD-Data มันต่างกันอีกนิดหน่อย สรุปคร่าวๆ ได้ตามการออกแบบว่า
- CD Audio ไม่ต้องการความถูกต้องของข้อมูลมากนัก เสียงผิดไปนิดๆ หน่อยๆ ฟังไม่ทันหรอก ผิดกับ Data ที่ผิดไปบิตนึง ก็หาชิบไม่เจอแล้ว
- CD Audio เน้น "ความต่อเนื่อง" ในการอ่าน คืออ่านไปเนี่ย ห้ามสะดุด ไม่งั้นเพลงกระตุกแน่, ในขณะที่ Data ไม่เน้นเท่าไหร่ ถ้าอ่านแล้วไม่แน่ใจว่าข้อมูลถูกไหม ก็อ่านซ้ำไปใหม่ได้

เทียบๆ กันกับการส่งข้อมูลบนเครือข่ายก็ได้ว่า Audio คล้ายๆ UDP ส่วน Data คล้ายๆ TCP

เมื่อความต้องการในการใช้งานไม่เหมือนกัน การออกแบบมันก็เลยไม่เหมือนกัน คือ CD Audio จะมีข้อมูลสำหรับตรวจสอบการผิดพลาดน้อยกว่า (ประมาณว่า ถ้าเก็บเพลงเนี่ย จะเก็บได้ 800MB แต่ถ้าเก็บข้อมูล จะได้แค่ 700 เพราะเอาอีก 100 ไว้กันพลาด)

ถัดมา เนื่องจากข้อมูลกันพลาดของ Audio CD มีจำนวนน้อยกว่า ก็อาจจะคิดได้ว่า ถ้ามันเสีย ก็เสียง่ายกว่า.. ถูกแล้ว แต่นอกจากนี้ มันยังมีเรื่องเครื่องอ่านอีกด้วย คือ...

เครื่องอ่าน CD เนี่ย.. ก็ทำตามหลักการออกแบบด้านบนนั้นเหมือนกัน คือถ้าเป็น Data อ่านผิดก็อ่านใหม่, แต่ถ้าเป็น Audio อ่านผิด เราไม่อ่านใหม่ แต่เราจะข้ามไปเลย ด้วยกลไกการแก้ไขข้อผิดพลาดของ CD ทำให้มันสามารถข้ามข้อมูลที่อ่านผิดไปแต่ยังเล่นเพลงต่อได้, ลองนึกสภาพว่า มันไม่ข้าม แล้วกลับมาอ่านใหม่ เพลงก็จะหยุด (buffer ใน drive มันน้อยครับ, นึกถึง CD ในรถ เวลาขับบนถนนขรุขระดูได้เลย)

กลไกการอ่านแผ่นแบบอ่านอะไรได้ก็เอาไว้ก่อนมันใช้ได้กับการเล่นแผ่นเพลงก็จริง แต่พอเอามา rip มันก็มีปัญหาว่าไอ้ที่ rip เนี่ย มันถูกจริงไหม เค้าก็มีเทคนิคหลายอย่างที่ช่วยให้แน่ใจ เช่น อ่านซ้ำหลายๆ ครั้ง, เช็ค CRC ฯลฯ ซึ่งเมื่อ rip ได้มาเป็นไฟล์แล้ว, ไฟล์นั้นก็จะมีข้อมูลเหมือนเดิมตลอดไป ไม่เปลี่ยน (ยกเว้นว่า HDD พัง ฮ่าๆๆ)

ทีนี้ มาเทียบการเล่นเพลงจาก CD กับไฟล์ที่ Rip มาจากแผ่นเดียวกัน
จากที่กล่าวไปข้างต้น จะเห็นได้ว่า การเล่นเพลงจาก CD นี่มันไม่แน่ไม่นอนเอาซะเลย เพราะถ้ามันอ่านพลาดปุ๊บ มันก็จะเริ่ม "เดา" ข้อมูล ณ ขณะนั้น ทันที ซึ่งแต่ละครั้งที่ฟัง ก็ไม่สามารถรับประกันได้ว่าข้อมูลมันเหมือนเดิม (เพราะอ่านแบบเอาเร็วเข้าว่า - นี่อาจจะเป็นสาเหตุว่า ทำไมเครื่องเล่น CD บางรุ่น ถึงราคาสูงลิ่วเพื่อรับประกันว่าจะอ่านได้หมด ไม่ต้องเดา~~ // ซึ่งจริงๆ แค่ปรับ hardware กับ algorithm ของ firmware ก็ได้แล้ว~~)

ในขณะที่การเล่นเพลงจากไฟล์ ที่มันเหมือนเดิมตลอด (การอ่านข้อมูลจาก HDD ก็มีการตรวจสอบนะครับ แล้วก็ไม่ใช่แบบอ่านอะไรได้ก็อ่าน) แล้วก็อย่าลืมว่า ไฟล์เพลงที่ rip ได้ มันพิสูจน์ข้อมูลของ CD ด้วยวิธีการต่างๆ มาแล้ว ไม่ใช่ "เดา" ใหม่ทุกครั้งอย่างที่เครื่องเล่นแผ่นทำ

เพราะฉะนั้น ถ้าถามผมว่า เล่นเพลงจากไฟล์ (lossless) กับจากซีดี อันไหนเสียงเหมือนเดิมมากที่สุด ก็คงต้องบอกว่าจากไฟล์ (ขอใช้คำว่าเหมือนเดิม, ไม่ใช่คำว่า "ดี" เพราะที่บางคนบอกว่าเสียงจากซีดีดีกว่า อาจจะเพราะเครื่องมัน "เดา" ข้อมูลได้ออกมาเจ๋งกว่าข้อมูลจริง)

ส่วนที่มีการกล่าวว่า CD ที่ Rip จาก Drive คนละเครื่อง จะได้ข้อมูลไม่เหมือนกัน อันนี้ผมไม่ได้ลอง ไม่สามารถบอกได้ว่าจริงไหม (drive เสียไปอันนึง Y-Y) แต่ถ้าเป็นจริง ก็สามารถอธิบายได้ว่า drive แต่ละตัว มัน "เดา" ข้อมูลที่มันอ่านไม่ได้ไม่เหมือนกัน เท่านั้นเอง ซึ่งก็อย่างที่บอก เวลาเอาไปเล่นจริงๆ มันก็เดาอีกอยู่ดีครับ

อย่างไรก็ตาม ก็อยากให้สังเกตว่า ที่มันไม่ได้เป๊ะๆ perfect ตรงส่วนนี้ ไม่ใช่ว่าเพราะความไม่แน่นอน แต่เพราะว่าเค้า "จงใจ" ออกแบบมาให้เป็นอย่างนี้ (ด้วยข้อจำกัดเทคโนโลยีตอนออกแบบ, ด้วยลักษณะการใช้ ฯลฯ) คือวิศวกรเค้าคิดมาดีแล้วครับ

สุดท้าย ขอฝาก accessory เล็กๆ น้อยๆ
ปุ่มไม้ปรับเสียงพร้อม "Good vibration" ที่จะทำให้เสียงดีขึ้น ราคาเพียง $485
ดูรายละเอียดได้จาก.. boingboing http://bit.ly/hpn9Zd , wired http://bit.ly/eZADuu

Wired ให้ความเห็นว่า: These ones, however, are very effective at one thing in particular: teleporting money out of customers’ pockets.

ไม่รู้จริงไหม.. แต่ฮา

อ่อ.. ปล นิดนึง
มีคนเค้าอ้างว่า "data communications กับ computer architecture ที่เรียนในปริญญาตรีส่วนใหญ่จะเรียนรู้ในพื้นฐานที่เน้นไปทาง software"

เข้าใจว่า.. ก็เรียนที่เดียวกันนะครับ, แต่ทำไมผมรู้สึกเหมือนได้เรียนเยอะกว่านี้ก็ไม่รู้

ถ้ามีข้อสงสัย ลองไปอ่าน Windows Sound Architecture กับ Soundcard Architecture (เช่น Intel HD Audio) ดูก็ได้ครับ


SSD vs HDD

posted on 04 Feb 2011 03:28 by ipats in Tech

เนื่องมาจากกระทู้นี้ http://www.taf.in.th/showthread.php?t=52000
ประเด็นคือ SSD ทำให้ "เสียงแห้ง"

ไอ้คำว่า "เสียงแห้ง" ในที่นี้ ผมก็ไม่สามารถบอกได้ว่ามันแห้งอย่างไร (ความชื้นสัมพัทธ์เป็น 0??)
แต่สามารถเข้าใจได้ว่า ถ้าเค้าเอามาเทียบกับ HDD แล้วจะสามารถบอกว่ามันต่างกัน

เมื่อกลางวันก็โต้กันไปยาว ยังไม่ได้ข้อสรุป
มีคนเสนอว่าให้ทำ blind test แต่ยังไม่ได้นัดแนะอะไรกัน
ก็เลยขอมาอธิบายทฤษฎีที่ผมเข้าใจมาไว้ก่อน

 

อนึ่ง ผมขอตัดประเด็น EMI ของอุปกรณ์ต่างๆ เช่น HDD, PSU ออกไปก่อน
เพราะใน scope ที่พูดถึงนี้ EMI จะมีผลเพียงแต่กับวงจร DAC

[หรือว่า.. EMI ของ HDD อาจทำให้มี noise เกิดที่ DAC ทำให้เสียงเปียก อันนี้มิทราบได้]

 

ก่อนจะไปต่อ ขออธิบายเล็กๆ น้อยๆ
1. การติดต่อของอุปกรณ์ต่างๆ ในคอมพิวเตอร์ (I/O) แทบทุกตัวจะมีหน่วยความจำก้อนนึง ที่เรียกว่า buffer (ปล. นอกจาก buffer จะใช้ติดต่อระหว่างอุปกรณ์ต่างๆ แล้ว มันก็ใช้ในการพักข้อมูล เพื่อรอการประมวลผลได้ด้วย)

buffer ทำหน้าที่คล้ายถังน้ำ คือ สมมติว่า เราอาบน้ำแบบขันตัก มีน้ำอยู่ในถัง เราก็ตักมาอาบได้สบาย ถ้าน้ำมันลดลง เราก็เปิดก็อก เพื่อให้น้ำไหลเข้ามาเพิ่ม ทีนี้ ทุกคนก็น่าจะพอนึกออกว่า

1.1 เราไม่จำเป็นต้องรอให้น้ำมันลดจนเหลือก้นถังตักไม่ขึ้น แล้วค่อยเปิดน้ำเข้ามา

1.2 ถ้าอัตราน้ำที่ไหลเข้า น้อยกว่าที่เราใช้อาบน้ำ ถ้าเราอาบไปเรื่อยๆ จนถึงจุดหนึ่ง น้ำจะหมดถัง (เรียกว่า buffer underrun/underflow) แต่ถ้าอัตราน้ำที่ไหลเข้า มากกว่าที่เราใช้ ในช่วงเวลาหนึ่ง มันก็จะล้น (buffer overflow/overrun) ถ้าไม่ให้มันล้น เราก็ต้องปิดน้ำ

1.3 ในระบบที่อัตราน้ำไหลเข้า น้อยกว่าอัตราที่ใช้มากๆ เราจะต้องมี buffer ขนาดใหญ่ขึ้น เพื่อชะลอการ "หมด" ของน้ำในถัง ให้อยู่ในระบะเวลาที่ยอมรับได้, นึกถึงว่า ถ้าถัง 20 ลิตร เราอาจจะอาบน้ำได้แค่ 5 นาที แล้วต้องนั่งรออีก 5 นาที เพื่อให้มีน้ำพออาบต่อ แต่ถ้าเรามาตุ่ม 200 ลิตร อาบน้ำจนเสร็จ เราใช้แค่ 100 ลิตร ก็ยังมีน้ำเหลืออีกตั้งครึ่งนึง แล้วกว่าเราจะอาบน้ำครั้งต่อไป น้ำก็จะไหลมาเต็มถังแล้ว

1.4 ส่วนในระบบที่อัตราน้ำไหลเข้า มากกว่าที่ใช้ไป เราจะต้องมีการ "ปิดก็อก" เพื่อไม่ให้น้ำล้นออกจากถัง และ "เปิดก็อก" เมื่อน้ำลดลงจนถึง "จุดหนึ่ง" เพื่อเติมน้ำให้มีปริมาณ "เหมาะสม" ทีนี้ ประเด็นมันก็คือ 1.4.1 ทำไมเราไม่ลดอัตราเร็วของน้ำเข้า ให้เท่ากับน้ำออก 1.4.2 "จุดหนึ่ง" และ "เหมาะสม" คือจุดไหน เท่าไหร่

เนื่องจาก Computer Bus I/O ส่วนใหญ่มัน Shared ซึ่งก็คือ หลายๆ อุปกรณ์ จะร่วมกันใช้งาน "เส้นทางข้อมูล" เดียวกัน

จินตนาการว่า เราอาบน้ำในห้องน้ำรวม มีถังน้ำ 4 ใบ ก็อกน้ำ 4 ก็อก อาบพร้อมกัน 4 คน (แก้ผ้าหรือเปล่าไม่รู้นะ! :p) แต่มีสายยางให้ 1 เส้น และก็อกกับถัง ก็อยู่ห่างกัน เงื่อนไขการอาบน้ำคือ แต่ละคน อาบได้เฉพาะน้ำในถังของตัวเอง แต่ถังแต่ละถัง จะเติมได้เฉพาะน้ำจากก็อกของตัวเองเท่านั้น โดยต้องใช้สายยางที่มีให้ 1 เส้น

เรื่องก็ไม่ยากเลย เพียงแค่เราผลัดกันใช้สายยางทีละคน (แบ่งกันใช้ bus) เติมน้ำให้พอใช้ แต่ไม่ล้นถัง เสร็จแล้วก็เอาสายยางให้คนอื่น แล้วเราก็อาบน้ำในถังไป พอน้ำลดลง (จะใกล้หมด หรือไม่ใกล้หมดก็ไม่รู้หล่ะ แต่มันมีที่เหลือพอให้เติม) เราก็ไปเอาสายยางมาใช้เพื่อเติมน้ำ แต่ก็ใช่ว่าเราจะเอาสายยางมาได้เลย เพราะเพื่อนอาจจะใช้อยู่ อาจจะยังไม่ถึงคิวเรา (schedule) ฯลฯ หรือเพื่อนบางคนอาจจะขาใหญ่ ขอใช้คนเดียวนานๆ (priority) เรื่องพวกนี้เป็นปลีกย่อย แต่ประเด็นคือ ถ้าทุกคนร่วมมือกันใช้สายยางอย่าง "พอเพียง" (คือไม่มีใครยืดเอาไว้นานๆ) นั่นคือ ทุกคนต้องเอาน้ำใส่ถังตัวเองให้เร็วที่สุด เพื่อปล่อยสายยางให้คนอื่นใช้ (อธิบาย 1.4.1 ว่า ทำไมไม่ลดอัตราเร็วของน้ำ)

ส่วน 1.4.2 นั้น ต้อง optimize เป็นกรณีไป แต่โดยหลักทั่วไปคือ ถ้าน้ำในถังเหลือน้อยเมื่อเทียบกับอัตราการช้ จะได้ priority สูงกว่า คนที่น้ำเหลือเยอะกว่า และการใส่น้ำ เราก็ไม่จำเป็นต้องใส่ให้เต็มทีเดียว ถ้าเราเห็นคนที่น้ำใกล้หมด เราก็สละสายยางไปให้ก่อนได้

1.5 จาก 1.4 นั้น เอามาเทียบกับ computer ได้ว่า คน 4 คนที่อาบน้ำพร้อมกันคือ CPU ที่กำลังทำงาน (อาบน้ำ) ของ process แต่ละตัว ที่ต้องการข้อมูล (น้ำ) พร้อมๆ กัน ทีนี้ ลองคิดไปว่า ถ้าขณะเปลี่ยนสายยาง คนทั้ง 4 ต้องมาเปลี่ยนกันเอง มันก็จะเสียเวลาอาบน้ำ (วิธีนี้เรียกว่า Program I/O) ต่อมา ก็เลยมีคนคิดตัวช่วยให้ เป็น "คนเปลี่ยนสายยาง" หรือเรียกว่า DMA - Direct Memory Access ซึ่งช่วยประหยัดเวลามากขึ้น เพราะไม่ต้องไปคอยเปลี่ยนสายยางเอง CPU (คน) ก็สามารถทำงาน (อาบน้ำ) ต่อไปได้ (จริงๆ อาจจะเทีบยแบบนี้ไม่ได้ตรงเท่าไหร่นัก แต่คิดว่าน่าจะพอให้เห็นภาพนะครับ)

2. การเล่นไฟล์เพลงโดยคอมพิวเตอร์นั้น มีขั้นตอนคร่าวๆ ตามนี้ครับ

2.1 Player ต้องการข้อมูลของเพลง จึงทำการส่งคำขอไปบอก OS ว่า "ฉันต้องการข้อมูลของไฟล์นี้ ไปเอามาให้ฉันหน่อย เดี๋ยวเตรียม buffer ไว้รอรับนะจ๊ะ"

2.2 OS ก็ไปติดต่อกับ File System และ Disk Controller เพื่อให้มันส่งข้อมูลไฟล์ดังกล่าวมาให้ตามที่ Player ร้องขอ โดยใส่ไว้ใน buffer ที่ Player เตรียมไว้รอรับ

2.3 เมื่อ Player มีข้อมูลแล้ว ก็จะ "แปล" ข้อมูลในไฟล์ ให้อยู่ในรูปแบบที่อุปกรณ์กำเนิดเสียง (soundcard) เข้าใจ

2.4 Player บอกกับ OS หรือ Soundcard (แล้วแต่วิธีการ) แยกเป็น

2.4.1 ถ้าบอก OS - ก็ว่า "เนี่ย ฉันมีข้อมูลเสียง อยู่ตรงนี้นะ (กองไว้ในใน buffer) มาเอาไปสร้างเสียงให้ที" แล้ว OS ก็จะนำข้อมูลใน buffer ตรงนี้ไป mix กับเสียงอื่นๆ หรือปรับแต่งต่างๆ ก่อนส่งไปให้ soundcard

2.4.2 ถ้าบอก soundcard - ก็คือ ข้ามขั้นตอนของ OS ใน 2.4.1 ไป แล้วส่งข้อมูลให้ soundcard เลย

ซึ่งในระหว่างนี้ Player ก็ยังคงแปลข้อมูลอยู่ และเมื่อข้อมูลที่จะต้องแปลมันลดลง ก็คอยบอก OS ว่า "เอาข้อมูลมาเพิ่มให้ด้วยนะ"

2.5 เมื่อ soundcard ได้รับข้อมูล (ซึ่งข้อมูลที่ได้รับนี้ จะไปอยู่ใน device buffer ของ soundcard) ก็จะนำมาสร้างเสียงต่างๆ โดย OS (2.4.1) หรือ Player (2.4.2) จะต้องส่งข้อมูลมาให้เรื่อยๆ ตลอดเวลา

จะเห็นว่า ทั้ง OS, Disk, Player, Soundcard ต่างทำงานพร้อมๆ กัน ขนานกันไป
เอ๊ะ แล้ว CPU ก็ถูกใช้งานหนักมากซิ? เปล่าเลยครับ

CPU นั้น จริงๆ จะถูกใช้งานเพียงแค่การ "แปล"  ของ Player และการควบคุมต่างๆ เท่านั้น (การควบคุมคือ บอกว่า ให้เอาสายยางไปเสียบก็อกไหน) เช่น OS จะบอก Disk Controller ว่า ต้องการข้อมูลบล็อกนี้ เอาไปไว้ที่หน่วยความจำตรงนี้นะ ตรงนี้ใช้ CPU แต่กระบวนการตั้งแต่ Disk Controller ติดต่อกับ Disk แล้วเอาข้อมูลมาใส่ใน RAM อันนี้ตัว Disk Controller และ DMA Controller เป็นคนจัดการทั้งหมด, CPU ก็ไปคอยทำงาน หรือคุมงานอื่นๆ ต่อ และนอกจากนี้ ขั้นตอน "การแปล" (decode) ของ player เมื่อเทียบกับการ "สังเคราะห์เสียง" ของ soundcard ยังเร็วกว่ามากอีกด้วย (น้ำไหลเข้าเร็ว แต่ใช้ออกไปน้อย)

3. latency คืออะไร เกี่ยวอะไรกับ buffer

latency ถ้าพูดให้เข้าใจง่ายๆ ก็คือ การดีเลย์ เช่น เรากดสวิตช์ไฟไปแล้ว แต่อีก 2 วิ ไฟถึงติด ง่ายๆ แค่นี้แหละครับ

ทีนี้ย้อนกลับไปดูที่ข้อ 2.4 นะครับ เอา 2.4.2 ก่อน จะเห็นว่า เรามี buffer ของ soundcard อยู่จำนวนหนึ่ง ซึ่งขนาดของ buffer ตรงนี้แหละ ที่ทำให้เกิด latency

จินตนาการถึง บูทชิมกาแฟร้อนนะครับ พนักงานจะเอากาแฟออกจากกาใส่แก้วเล็กๆ เรียงไว้ สมมติว่า

กรณีแรก ไม่มีแก้วที่ใส่กาแฟอยู่เลย พอลูกค้ามา พนักงานถึงเอากาแฟมาใส่แก้ว แล้วส่งให้ลูกค้า ลูกค้าจะได้กาแฟที่ร้อนเสมอ (no buffer/no latency ไม่มีดีเลย์ระหว่างเวลาที่เอากาแฟออกจากกา ถึงมือลูกค้า) แต่จะเสียเวลาให้ลูกค้าคอยนาน
กรณีที่สอง เพื่อไม่ให้ลูกค้าคอย พนักงานจึงเอากาแฟใส่แก้วไว้จนเต็มบูท เรียกได้ว่า ลูกค้ามาเมื่อไหร่ หยิบเสริฟได้ทันที ข้อเสียคือ ลูกค้าจะไม่ได้กาแฟร้อนๆ เลย และบางทีกาแฟจะเย็นจนกินไม่ได้ หรือ ลูกค้าหมดแล้ว กาแฟเหลือ (large buffer/large latency/waste resource)
กรณีสุดท้าย พนักงานต้องสังเกต และหาดูว่า อันตราลูกค้าเข้ามาเท่าไหร่ และควรจะริยกาแฟไว้กี่แก้ว เพื่อไม่ให้เสียรสชาติกาแฟมากเกินไป (optimal buffer/acceptable latency)

ทีนี้ในการเล่นเพลง latency มีผลอย่างไร กรณีแรก ถ้าไม่มี buffer เลย ข้อมูลมาปุ๊บ เล่นเสียงเลย แต่ถ้าข้อมูลขาดช่วงเมื่อไหร่ จบ กระตุกทันที

กรณีที่สอง buffer ใหญ่เกินไป ข้อมูลส่งมาตั้งนานแล้ว ยังไม่ได้เล่น พอเราเปลี่ยนแปลงข้อมูล (เช่นเปลี่ยน EQ) ก็ต้องรอนาน กว่าจะมาเล่นถึงข้อมูลใหม่

กรณีสุดท้าย ดีที่สุด (ก็มัน optimal หน่ะซิ) แต่ว่า optimal มีขนาดเท่าไหร่ อันนี้ขึ้นอยู่กับสถานการณ์ ถ้าฟังเพลงอย่างเดียว ดีเลย์เป็นวินาที ก็ไม่กระทบอะไรเลย แต่ถ้าใช้ในงาน synth, mix อะไรพวกนี้ อาจจะยอมรับได้แค่ ไม่กี่มิลลิวินาที (คือเปลี่ยนค่าไปแล้ว เสียงต้องเปลี่ยนเลยทันที)

ทีนี้มากดูสมมติฐานจากกระทู้ทีละข้อ

H1: seek time ปกติ 10 กว่า ms แต่ ssd ไม่ถึง 1ms คิดเอาว่าตอนเล่นเพลงจริงๆ จังๆ ที่ playback latency 0-5ms จะเป็นไง
F1: seek time ของ storage ไม่มีผลกับการเล่นเพลง ไม่ว่าจะ playback latency (device buffer) เท่าไหร่ ตราบเท่าที่มันสามารถอ่านข้อมูลออกมาได้เร็วกว่า bitrate ของเพลง (ซึ่ง CD Quality PCM WAV ต้องการไม่ถึง 1 MB/s) เพราะมันมี buffer ของข้อมูลเพลง ซึ่งข้อมูลเพลงจะถูกเก็บไว้ตรงนี้ และเมื่อ Player ต้องการ ก็มาเรียกเอาจากตรงนี้ได้เลย ไม่ใช่ว่า จะ decode แล้วไปเรียกเอาข้อมูลจาก disk แล้ว disk ถึงจะ seek ไปหาข้อมูลอีกที และ buffer ตรงนี้ ไม่ก่อให้เกิด latency (เพราะ latency ในที่นี้ เกิดที่ soundcard) ข้อเสียอย่างเดียวของ buffer นี้คือ เปลืองแรม

 

H2: ข้อมูลจาก drive ส่งไปใน sata controller ไม่ใช่เลข 0 กับ 1 แต่เป็น sine wave ซึ่งช่วงตัดจะไม่ได้เป๊ะๆพอดี
F2: ข้อมูลที่ส่งใน SATA ใช้เทคนิคที่เรียกว่า differential signaling ซึ่งไม่ไม่เกี่ยวว่ามันจะเป็น square wave หรือ sine wave แต่ถ้ามันมี error ซึ่งตรวจได้ เพราะใน packet มี crc มันก็ส่งมาใหม่ ไม่ใช่ว่าส่งข้อมูลมาผิด แล้วจะเอาไปใช้ผิดๆ ไม่เช่นนั้น เราจะทำอะไรกับคอมพิวเตอร์ไม่ได้เลย เพราะโปรแกรมแต่ละโปรแกรม แค่ผิดไปบิตเดียว ก็อาจทำให้มันค้าง หรือทำงานผิดพลาดได้

 

H3: เมื่อลอง set nt timer resolution จาก 15.6 มา 0.5ms และทดลองด้วย WASAPI ที่ playback latency <= 5ms จะฟังออกว่าต่างได้อย่างไม่ยากเย็นเลย โดยปกติ application timer จะ fetch คำสั่งใหม่ๆทุก 15.6ms
F3: เรื่องฟังต่างกันไหม ไม่สามารถทราบได้ ไม่ได้ทดลอง แต่ timer ไม่ใช่ fetcher ไม่ใช่ scheduler มันเป็นเพียง counter ที่บอกว่า ตอนนี้ เวลาผ่านมาแล้วเท่าไหร่ การทำงานของคอมพิวเตอร์ จะ fetch คพสั่งต่างๆ มาจากโปรแกรมเป็นหลักพันล้านครั้งต่อวินาที (ถ้า ideal คือ เท่ากับความถี่ clock ของมันนั่นแหละ) เข้าใจว่า ที่เค้าพูดถึง อาจจะหมายถึงการเขียนโปรแกรมแบบ timer-driven ที่มันจะทำงานได้ด้วยความถี่สูงสุดเท่านั้น แต่ก็ไม่ได้หมายความว่า แต่ละครั้ง ที่โปรเซสนั้นทำงาน มันจะทำได้อย่างเดียว

 

อื่นๆ

H4: buffer มากๆ ทำให้เสียงดีเลย์ และเพี้ยน?
F4: ในกรณีนี้ เข้าใจว่าเป็น device buffer ของ sound card, เสียงดีเลย์ ใช่ครับ แต่ดีเลย์ไปพร้อมๆ กันหมด ไม่ได้เลือกว่า ความถี่นี้ดีเลย์เยอะ ความถี่นี่ดีเลย์น้อย ซึ่งมันก็ทำให้เสียงมันเหมือนเดิม มันไม่เพี้ยนไปหรอก มันเป็นไปไม่ได้เลย ที่จะบอกว่า buffer มาก แล้วเสียงทุ้ม ไม่ลื่นไหลเพราะมีข้อมูลมากเกินไป

H5: เซ็ต soundcard device buffer น้อยๆ แล้วต้องมี storage ที่ความเร็วสูง latency ต่ำ ถึงจะใช้งานได้
F5: กลับไปอ่านที่ F1 และ 2.2 ครับ device buffer มันไม่ได้มีกงการอะไรกับ storage buffer เลยซักนิดเดียว มันเป็นคนละตัวกัน

อ่านมาถึงตรงนี้ ถ้าสงสัยอะไรถามต่อได้ครับ และสามารถสรุปได้เลยว่า access time ของ SSD/HDD ไม่มีผลอะไรกับเสียงที่ออกมา

ถ้าจะมีผลที่ทำให้เสียงเปลี่ยนแปลง อาจเกิดได้เนื่องจากการรบกวนทางกระแสไฟฟ้า เนื่องจาก HDD มีมอเตอร์ เวลามันหมุน/สตาร์ท มันส่งการรบกวนได้ครับ ส่วน solid-state (ทั้ง RAM และ SSD) ก็เช่นกัน ถ้าวงจร DAC ไม่ดีพอ มันก็เอามารวมในเสียงที่ออกไปนี่แหละ แต่แน่นอนว่า ไม่เกี่ยวกับข้อมูล input เพราะมันไม่เปลี่ยนแปลง ไม่ว่าจะเอามาจาก HDD/SSD/USB Drive/Network Stream ตราบใดที่มันส่งข้อมูลมาได้ด้วยอัตราเร็วพอ และมี buffer ขนาดใหญ่พอ มันก็เล่นเพลงได้เหมือนกันหมด

มีเว็บไซต์บางแห่ง "อ้างว่า" ยิ่ง buffer ใหญ่เท่าไหร่ เวลานำข้อมูลออกจาก buffer จะเอาออกมากขึ้น และทำให้เกิด electrical burst ทำให้วงจรทำงานผิดพลาด, ถามว่าเป็นไปได้ไหม ก็อาจเป็นไปได้ เพราะฉะนั้น ถ้าคิดว่ามันมีผลจริงๆ ผมแนะนำวิธีให้คือ ไม่ต้องให้ DAC ของ soundcard ทำงาน ให้ส่งข้อมูลออกเป็น digital (ซึ่งมีระบบป้องกันข้อมูลผิดพลาดมากพอจะสู้กับ electrical burst interference ได้) แล้วต่อไปยัง DAC ภายนอก ที่ใช้แหล่งจ่ายไฟที่ไม่เกี่ยวข้องกัน โดยต้องต่อผ่าน optical link เพื่อป้องกันกระแสไฟฟ้ารบกวนตามมา (ซึ่งก็ไม่เกี่ยวกับ SSD/HDD อีกอยู่ดี)

ขอจบเพียงเท่านี้ มีอะไรสงสัยถามมาได้ครับ ผิดพลาดก็ขออภัย
จริงๆ มี waveform ที่ทำเปรียบเทียบอย่างบ้านๆ อยู่ แต่ยาวแล้ว เดี๋ยวไว้ลงอีกตอน