Microphone mảng pha (2023)

 (benwang.dev)
1 điểm bởi GN⁺ 2024-11-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Microphone mảng pha 192 kênh có thể thay đổi tính định hướng ngay cả sau khi ghi âm, hoặc lấy nét đồng thời vào hàng trăm nghìn điểm, cho phép ước tính và trực quan hóa vị trí nguồn âm — điều khó làm với microphone định hướng thông thường
  • Phần cứng gồm các tay microphone dạng nan hoa và một hub trung tâm; với chi phí khoảng $700, sử dụng 192 microphone MEMS, card FPGA Colorlight i5 và kiến trúc truyền Gigabit Ethernet
  • FPGA tập trung vào truyền dữ liệu PDM thô thay vì tiền xử lý phức tạp, xử lý đầu vào 3.125MHz và dùng khoảng 715Mbps, tương đương khoảng 70% băng thông Gigabit Ethernet
  • Phần mềm kết hợp bộ lọc CIC, hiệu chuẩn dựa trên FFT, tối ưu GPU và beamforming bằng Triton để trực quan hóa thời gian thực vị trí nguồn âm 3D trường gần và 2D trường xa
  • Có thể bắt các gói UDP bằng tcpdump để phát lại, nhưng lưu thô đạt tới 87.5MB/s, cần 315GB cho 1 giờ ghi âm

Cấu hình microphone mảng pha 192 kênh

  • Kết hợp microphone mảng pha 192 kênh với thu thập dữ liệu bằng FPGA và beamforming/trực quan hóa dựa trên GPU
  • Khác với microphone định hướng thông thường, mảng pha có thể thay đổi tính định hướng ngay cả sau khi ghi âm và có thể lấy nét đồng thời vào hàng trăm nghìn điểm trong thời gian thực
  • Toàn bộ thiết kế được công bố dưới dạng mã nguồn mở

Thiết kế phần cứng

  • Cấu trúc mảng và chi phí

    • Tạo mảng pha bằng cách bố trí nhiều microphone với phân bố khoảng cách rộng
    • Với mảng tuyến tính, khoảng cách theo hàm mũ giữa các microphone được biết là tối ưu cho tín hiệu băng rộng
    • Mảng 2D bố trí các tay mảng tuyến tính đối xứng theo dạng nan hoa để giữ bo hub trung tâm nhỏ
    • Tổng chi phí của mảng khoảng $700

  • Bo tay

    • Chiều dài mỗi tay được điều chỉnh theo giới hạn sản xuất/lắp ráp PCB; chiều dài tối đa cho sản xuất/lắp ráp PCB 4 lớp của JLCPCB là 570mm
    • Microphone dùng loại MEMS đầu ra số giá rẻ, khoảng $0.5 mỗi chiếc
      • Ở mức giá này, khác biệt hiệu năng giữa các microphone không lớn
      • Phần lớn có hiệu năng ổn đến 10kHz, nhưng độ trễ pha và cân khớp âm lượng không được nêu rõ
    • Microphone xuất dữ liệu theo dạng PDM (pulse density modulation)
      • Xuất 1 bit ở tần số tối đa 4MHz, cao hơn nhiều so với dải nghe được
      • Bù nhiễu lượng tử hóa bằng tốc độ lấy mẫu cao
      • Hỗ trợ DDR, chốt dữ liệu ở cạnh lên/xuống của clock, nên có thể ghép kênh hai microphone trên một đường dây
    • Mỗi tay có 8 microphone và 4 đường đầu ra, với bộ đệm đầu ra trên đường clock đầu vào
    • Thiết kế để thời gian sườn lên vẫn duy trì ở mức hợp lý ngay cả khi hàng trăm microphone dùng chung cùng tín hiệu clock
    • Tỷ lệ đạt của PCB tay không tốt; số bo hoạt động ở trạng thái ban đầu chỉ khoảng 50%
      • Lỗi phổ biến nhất là đường clock bị chập vào 3V3 hoặc GND
      • Để xử lý chập cần thử-sai bằng cách tháo từng microphone
      • Một số microphone vẫn xuất dữ liệu sai sau khi rework, và mã sẽ mask để loại trừ các microphone đó
    • Ở thiết kế tiếp theo, có thể giảm rework bằng điện trở nối tiếp trên đường clock, cải thiện panel hóa và cải thiện stencil kem hàn

  • Bo hub

    • Việc thu thập dữ liệu dùng FPGA, vì cần nhiều I/O độ trễ thấp và giao diện tốc độ cao như Gigabit Ethernet
    • Cụ thể, chọn card Colorlight i5
      • Lý do là có đủ I/O, giá thấp, dễ mua và có hai Ethernet PHY tích hợp
      • Dự án này chỉ dùng một Ethernet PHY
    • Card này vốn là giao diện Ethernet cho panel LED nhưng đã được reverse engineer hoàn toàn
    • Khoảng 100 GPIO được đưa ra qua đầu nối DDR2, nên fan-out dễ hơn so với BGA của FPGA gốc
    • Ngoài FPGA, hub còn có mạch quản lý nguồn đơn giản, đầu nối cho bo tay và đầu nối Ethernet có magnetics tích hợp

  • Thiết kế cơ khí

    • Các tay được gắn vào hub bằng standoff/đai ốc gắn PCB và vít M3
    • Kết nối giữa tay và hub dùng đầu nối 8 chân pitch 2mm
    • Thiết kế ban đầu cho các khe trên PCB tay ăn khớp với PCB cấu trúc theo chu vi, nhưng độ cứng xoắn của tay thấp khiến toàn bộ cấu trúc dễ biến dạng
    • Thiết kế cuối cùng đặt các mảnh MDF 1/4 inch cắt laser ở vành ngoài mảng và cố định từng tay vào MDF bằng dây rút
    • Mảng microphone gắn trên tường nên dễ bị phản xạ; để hiệu chuẩn dễ hơn, phản xạ được giảm bằng mút tiêu âm

Gateware FPGA

  • Mục tiêu thiết kế

    • Mục tiêu cốt lõi của gateware là truyền ổn định dữ liệu thô đã thu thập về máy tính mà không mất dữ liệu
    • Nếu decimation và lọc trên FPGA thì có thể giảm tốc độ dữ liệu, nhưng dữ liệu PDM thô cũng có thể truyền qua Gigabit Ethernet
    • Gửi dữ liệu thô giúp giảm độ phức tạp của mã FPGA và tăng tốc quá trình phát triển lặp
    • Biên dịch mã nhanh hơn place-and-route, và dùng debugger trong mã thông thường dễ hơn debug gateware

  • Giao diện PDM

    • Module đầu vào PDM chia clock hệ thống 50MHz cho 16 để xuất clock PDM 3.125MHz
    • Sau mỗi cạnh clock, chốt 96 chân đầu vào và dịch dữ liệu 32 bit ở mỗi chu kỳ clock
    • Gắn header số nguyên tăng dần 32 bit vào mỗi chunk dữ liệu 192 bit
    • Tốc độ dữ liệu đầu vào của giao diện PDM là 3.125MHz × 96 chân đầu vào × DDR 2 = 600Mbps
    • Tốc độ dữ liệu đầu ra gồm header là 700Mbps, mức sử dụng đường dữ liệu đầu ra 32 bit khoảng 40%

  • Đóng gói và truyền UDP

    • Module đóng gói gần giống một bộ đệm FIFO với giao diện đầu vào đặc biệt
    • Vì giao diện Ethernet nhanh hơn đầu ra PDM, nếu hoạt động như FIFO tiêu chuẩn, chỉ cần có một mục là xuất ra thì có thể tạo gói nhỏ hơn yêu cầu
    • Module đóng gói đợi đến khi trong hàng đợi tích lũy đủ dữ liệu cho một gói rồi mới bắt đầu truyền, bảo đảm gói có kích thước cố định
    • Mỗi gói chứa 48 khối đầu ra PDM 224 bit
      • Mỗi khối gồm dữ liệu 192 bit và header 32 bit
      • Dữ liệu mỗi gói là 1344 byte
      • Thêm header IPv4 20 byte và header UDP 8 byte
    • Tốc độ gói khoảng 65kpps, kết quả là tốc độ đường truyền 715Mbps, mức sử dụng Gigabit Ethernet khoảng 70%
    • Streaming UDP dùng LiteEth
      • Trừu tượng hóa các độ phức tạp cấp thấp như đóng gói UDP/IP và bảng ARP
      • Cung cấp giao diện dễ nối FIFO với luồng UDP
      • Độ trễ ngắt quãng được hấp thụ bởi phần đệm dư trong FIFO đóng gói

  • Sử dụng tài nguyên FPGA

    • FPGA của Colorlight i5 là LFE5U-25F-6BG381C và có 25k LUT
    • Thiết kế được place-and-route bằng toolchain mã nguồn mở Project Trellis
    • Nhờ giữ gateware đơn giản, mức sử dụng tài nguyên thấp và còn nhiều dư địa để thêm tính năng
    • DP16KD: 16/56, 28%
    • TRELLIS_FF: 1950/24288, 8%
    • TRELLIS_COMB: 3701/24288, 15%
    • Clock tối đa đạt 73.17MHz so với mục tiêu 50MHz
    • Cảnh báo timing của clock Ethernet RX là false positive liên quan đến gray counter của LiteEth

Pipeline xử lý phần mềm

  • Bộ lọc CIC

    • Mỗi microphone xuất tín hiệu 1 bit 3.125MHz, cần giảm xuống tốc độ lấy mẫu và độ sâu bit thấp hơn để xử lý tiếp
    • Công việc này dùng bộ lọc CIC, vốn cần ít phép toán số học
    • Tham khảo loạt bài Moving Average and CIC Filters của Tom Verbeure
    • Lựa chọn cuối cùng là bộ lọc CIC 4 tầng, decimation 16 lần
      • Giảm tốc độ lấy mẫu xuống 195kHz
      • Đầu ra là 32 bit
    • Để nhận dữ liệu 3.125MHz, một nhóm mẫu phải được xử lý trong 320ns
    • Bản triển khai Rust đơn giản không đủ nhanh trên một core, nên cuối cùng dùng bản triển khai giảm abstraction để khuyến khích tự động vector hóa tốt hơn
    • Bản triển khai bằng SIMD intrinsic nhanh hơn nhiều, nhưng gặp vấn đề căn chỉnh khi dùng cùng mã khác
    • Kết quả benchmark:
      • bench_cic: 574ns/iter, 41MB/s
      • bench_fast_cic: 181ns/iter, 132MB/s
      • bench_simd_cic: 36ns/iter, 666MB/s

  • Hiệu chuẩn

    • Hiệu chuẩn mảng được thực hiện bằng cách phát white noise từ loa và di chuyển loa trong phòng phía trước mảng
    • Tính tương quan chéo dựa trên FFT giữa mọi cặp microphone để tìm độ trễ tương đối
    • Có hơn 18.000 cặp microphone nên khối lượng tính toán lớn
    • Với kích thước cửa sổ 16k~64k, FFT bị nghẽn bởi bộ nhớ, nên đã kết hợp IFFT và tìm đỉnh để không ghi kết quả ra bộ nhớ, đạt tăng tốc 15 lần
    • Trên Ryzen 7950X, quá trình này chạy theo thời gian thực
    • Sau đó tối ưu vị trí nguồn âm tại từng thời điểm và vị trí từng microphone bằng gradient descent
      • Hàm loss giảm chênh lệch giữa tương quan đo được và tương quan lý tưởng
      • Giữ cho vị trí microphone không lệch quá xa so với vị trí ban đầu
      • Cũng giảm jerk của quỹ đạo nguồn âm
    • Trong quá trình hiệu chuẩn, tốc độ âm thanh cũng được đưa vào làm tham số tối ưu, khiến toàn bộ quy trình hoạt động như một nhiệt kế quá phức tạp
    • Sau vài trăm vòng lặp, vị trí nguồn âm, vị trí microphone và các hằng số như tốc độ âm thanh hội tụ về nghiệm hợp lý
    • Bài toán này vector hóa tốt trên GPU và hội tụ chỉ trong vài giây
    • Sai số vị trí trung bình cuối cùng khoảng 1mm
    • Các méo hệ thống quy mô lớn như độ lõm do thiếu độ cứng kết cấu cũng được hiệu chuẩn bù lại
    • Sai số tối đa giữa vị trí thiết kế và vị trí hiệu chuẩn khoảng 5mm
    • Bước sóng của âm 10kHz khoảng 3.4cm, nên nếu không hiệu chuẩn có thể xuất hiện lỗi pha đáng kể ở tần số cao

Beamforming và trực quan hóa

  • Phương pháp beamforming

    • Beamforming là quá trình xử lý đầu vào microphone thô để tạo đáp ứng định hướng
    • Cách triển khai là delay-and-sum đơn giản nhất, tức DAS
    • Từng tín hiệu được làm trễ theo chênh lệch khoảng cách đến nguồn âm rồi cộng lại
    • Trong dự án này, beamforming được thực hiện trong miền tần số
      • Trong miền tần số, độ trễ được triển khai bằng hạng tử pha tuyến tính tỉ lệ với độ trễ cần thiết và phép nhân phức với tín hiệu
      • Các độ trễ không phải bội số nguyên của chu kỳ lấy mẫu cũng được xử lý tự nhiên
    • Nhiều tiểu mảng chồng lấp của mảng gốc được dùng theo từng dải tần
    • Không cần beamforming bằng mọi microphone ở mọi tần số, giúp giảm thông lượng xử lý và cũng giúp khớp gain beamforming trên mọi tần số

  • Triển khai GPU dựa trên Triton

    • Beamformer được triển khai bằng kernel Triton
    • Triton là Python DSL được biên dịch để chạy trên GPU Nvidia
    • Khi beamforming đến hàng trăm nghìn điểm, tính song song quy mô lớn của GPU cho phép có kết quả thời gian thực
    • Do hạn chế hiện tại liên quan đến hỗ trợ indexing mảng shared memory trong ngôn ngữ Triton, hiệu năng hơi chưa tối ưu, nhưng không chọn viết CUDA C++

  • Beamforming 3D trường gần

    • Beamforming 3D trường gần được thực hiện trên lưới voxel 5cm
    • Kích thước lưới là 64×64×64
    • Đạt tốc độ cập nhật 12Hz trên RTX 4090
    • Tốc độ cao hơn bị giới hạn bởi overhead đồng bộ CPU-GPU chưa tối ưu ở các đơn vị công việc nhỏ
    • Lưới voxel được trực quan hóa bằng thư viện trực quan hóa hiệu năng cao dựa trên OpenGL VisPy
    • Render 250.000 voxel bán trong suốt không phải vấn đề ở frame rate tương tác nếu so với số đa giác trong game hiện đại

  • Beamforming 2D trường xa

    • Với nguồn âm trường xa, mặt sóng gần như phẳng, nên khoảng cách xa bao nhiêu không làm thay đổi đáng kể tín hiệu của mảng
    • Nguồn âm gần có độ cong mặt sóng lớn, nên có thể xác định vị trí 3D
    • Beamforming trường xa không có chiều sâu nên có thể thực hiện ở độ phân giải cao hơn
    • Dùng lưới 512×512 pixel và cũng đạt tốc độ cập nhật 12Hz
    • Beamforming trường xa dùng phép xấp xỉ đặt điểm ở rất xa thay vì giả định sóng phẳng thực sự
    • Do có nhiều phản xạ và đa đường trong phòng, demo trực quan hóa 2D chịu ảnh hưởng của môi trường âm học

  • Âm thanh định hướng

    • Hai triển khai beamforming ở trên tính năng lượng âm thanh tại từng vị trí, nhưng không tạo âm thanh đã beamform trong bộ nhớ
    • Để ghi âm định hướng, đã triển khai beamformer delay-and-sum trong miền thời gian
      • Nhận tọa độ 3D tính từ tâm mảng làm đầu vào
      • Xuất mẫu âm thanh
    • Beamformer này khả vi theo vị trí đối với đầu ra
    • Có thể tối ưu vị trí nguồn âm bằng hàm loss khả vi
    • Một ứng dụng khả thi là dùng mô hình forced alignment trong phiên âm nhiều người để tìm vị trí vật lý của từng người nói
    • So sánh hiệu quả bằng cách một loa phát âm thanh trước mảng, còn loa khác phát white noise ở cùng khoảng cách nhưng lệch khoảng 45 độ so với tâm mảng
    • So sánh âm thanh thô từ một microphone đơn với âm thanh đã beamform để thể hiện hiệu quả beamforming

Cách ghi âm và giới hạn

  • Dữ liệu mảng microphone là các gói UDP, nên có thể ghi bằng công cụ như tcpdump
  • Có thể đọc file bắt gói và bơm lại các gói vào listener
  • Các chương trình nói trên được thiết kế để chạy thời gian thực, nhưng cũng hoạt động với dữ liệu ghi theo cách này
  • Nhược điểm là lưu nguyên dữ liệu thô, khiến tốc độ dữ liệu đầu ra rất cao
    • Lưu cả nhiễu lượng tử hóa một cách trung thực
    • Tốc độ dữ liệu là 87.5MB/s
    • 1 giờ ghi âm cần 315GB
  • Một triển khai tối ưu hơn có thể áp dụng nén hoặc ghi sau bộ lọc CIC ở tốc độ lấy mẫu thấp hơn

Các hướng mở rộng có thể

  • Dự án về cơ bản đã hoàn tất và không có kế hoạch làm thêm trong tương lai gần
  • Dù vậy, vẫn còn dư địa mở rộng cho người muốn tự làm
    • Dùng các thuật toán beamforming nâng cao hơn như DAMAS
    • GUI tốt hơn, kết hợp các tính năng hiện có như xem âm thanh phát ra từ đâu rồi ghi âm tại vị trí đó
    • Cũng có thể kết hợp beamforming khả vi với mô hình mạng nơ-ron, chẳng hạn các ứng dụng như ví dụ forced alignment

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-11-23
Các ý kiến trên Hacker News

  • Điều thú vị là trong quá trình hiệu chỉnh, tốc độ âm thanh cũng là một tham số được tối ưu hóa để có được mô hình tối ưu của hệ thống, nên toàn bộ quy trình hoạt động như một chiếc nhiệt kế được thiết kế quá mức đến phi lý
    Điều này làm tôi nhớ đến câu châm ngôn trong điện tử: “Mọi cảm biến đều là cảm biến nhiệt độ, và một số còn đo được thứ khác”

    • Hồi trung học, với sự giúp đỡ của bố mẹ, tôi đã làm một thiết bị đo áp suất giảm nhanh đến mức nào trong một xi-lanh được nén áp bị rò khí qua một lỗ rất nhỏ
      Hóa ra bằng cách đó cũng có thể đo nhiệt độ, và ngoại suy đồ thị để tìm độ không tuyệt đối
      Theo tôi nhớ thì kết quả lệch khoảng 20K, nhưng với một dự án trong gara của học sinh trung học thì tôi thấy khá tuyệt
    • Tôi có nguyên tắc là khi đo thứ gì đó theo thời gian thì nhất định cũng phải đo cả nhiệt độ môi trường
    • Tôi thích kiểu đo lường tình cờ như thế này
      Ví dụ tôi đặc biệt thích là một thiết bị đo quán tính (IMU) đủ chính xác có thể dùng hiệu ứng Coriolis để đo kinh độ tương đối chính xác
    • Không biết có câu châm ngôn kiểu “Mọi thiết bị điện tử đều là máy tạo khói, và một số còn tính toán được” không nhỉ
    • Tôi vừa mới biết Duracell Powercheck© hoạt động bằng cách dùng nhiệt độ
      https://youtu.be/zsA3X40nz9w?si=oGg2wdUlLXSDxpsN

  • Trước đây tôi từng làm một dự án đa phương vị cho dơi bằng một mảng 4 micro đặt trên mặt đất theo hình chữ Y lớn
    Dùng chênh lệch thời gian tín hiệu đến bốn micro, chúng tôi có thể xác định vị trí từng con dơi bay qua phía trên mảng và cả nhận dạng loài
    Nó được dùng trong nghiên cứu đánh giá tác động môi trường của việc lắp đặt tuabin gió, và khá thú vị

    • Làm tôi nhớ đến Optical Fence của Intellectual Ventures
      Đó là thiết bị được phát triển để theo dõi và tiêu diệt muỗi bằng các xung laser ngắn
      Vì cần xác định chính xác vị trí không gian của muỗi, nên như một hệ quả phụ, nó có thể phát hiện khác biệt tần số đập cánh và phân biệt mục tiêu theo giới tính và loài
    • Tôi đã làm một dự án tương tự hồi 18 tuổi
      Tất nhiên vì kỹ năng phần cứng và phần mềm còn thiếu, tôi triển khai thuật toán TDOA ở dạng ngây thơ nhất, và cách ước lượng chênh lệch thời gian bằng tương quan chéo cũng rất kém hiệu quả
      Dù vậy tôi học được rất nhiều, và cuối cùng nó dẫn tôi đến chương trình tiến sĩ về hệ thống SAR
      Tôi xem SAR thực chất gần giống một beamformer dùng chuyển động của nền tảng thay cho mảng
    • Tôi tò mò kết quả nghiên cứu ra sao
      Tôi từng nghe nói phổi dơi quá nhạy, nên nếu chúng bay xuyên qua chênh lệch áp suất của tuabin lớn thì các mao mạch gần như bị vỡ
    • Tôi muốn thử làm thứ như vậy để theo dõi dơi trong vườn, nhưng không biết với một dự án cá nhân thì người nghiệp dư làm có thực tế đến mức nào
      Giá mà có tài liệu tham khảo nào đó để biết nên bắt đầu từ đâu
    • Tôi cũng nhớ đến công trình tuyệt vời và âm thầm của Cosys-Lab tại Đại học Antwerp
      Họ đặt một mảng micro bên dưới một con bọ cạp và cho thấy dơi di chuyển chùm siêu âm như thế nào để quét con bọ cạp
      Kết quả thật sự đáng kinh ngạc [0]
      [0]: https://www.youtube.com/watch?v=57ScSPWhGqU

  • Tôi thắc mắc vì sao họ dùng PDM thay vì micro I2S TDM cho mảng
    ICS-52000 tương đối rẻ, khoảng 2 đô la khi mua 100 chiếc, có cả breakout board gắn 4 micro, và theo tôi hiểu có thể nối chuỗi đến 8 hoặc 16 chiếc
    https://www.cdiweb.com/datasheets/notwired/ds-nw-aud-ics5200...
    Nếu dùng Jetson hoặc phần cứng có DSP/GPU hỗ trợ I2S, có thể nối chuỗi 16 micro trên mỗi cổng I2S, nên việc lắp ráp và lập trình có vẻ dễ hơn nhiều so với cấu hình FPGA

    • Chi phí là yếu tố lớn nhất
      Với 192 micro, chênh lệch giữa 2 đô la/chiếc và 0,5 đô la/chiếc trở nên khá lớn
      Ngay cả khi nối chuỗi daisy-chain 16 chiếc, cũng khó tìm thiết bị có đủ giao diện I2S, và phần lớn thiết bị không có đủ số lượng cần thiết
      Bản thân FPGA và phần cứng tùy chỉnh cũng là một phần của niềm vui
    • Vài năm trước tôi có tìm hiểu, khi đó chúng đắt hơn và chỉ dùng được đến 20kHz
      Để nghe tiếng rít của khí rò rỉ hoặc phóng điện corona của hồ quang điện, tần số cao hơn rất hữu ích
      Orin có 6 cổng I2S nội bộ, nên có vẻ có thể hỗ trợ tới 16*6 = 96 micro, một con số khá tốt
      Tuy nhiên trên thực tế hình như chỉ có 3 cổng được đưa ra ngoài bo mạch và nằm trên các đầu nối khác nhau của dev board [1]
      Trong thiết kế, chi tiết luôn là vấn đề; nếu cần nhiều hơn 96 chiếc thì FPGA có thể dễ cấu hình hơn
      Các linh kiện tôi ghi chú là ICS-52000 $3.50 20kHz, ICS-41350 $1.05 40kHz, SPH0641LU4H-1 $1.45 80kHz+
      [1] https://docs.nvidia.com/jetson/archives/r34.1/DeveloperGuide...
    • Tôi từng định tự làm mảng pha, nhưng chưa đi đến bước chế tạo PCB
      Có khoảng hai lý do khiến I2S không phải lựa chọn tốt nhất
      I2S cần 3 chân thay vì 2 chân như PDM
      Tuy nhiên nếu có thể nối daisy-chain các micro như trong datasheet bạn đưa thì khá tuyệt, và dù không phải I2S tiêu chuẩn, luận điểm này sẽ không còn nữa
      PDM có thể tiếp cận tốc độ lấy mẫu cao hơn nhiều, nên linh hoạt hơn trong việc chọn độ trễ cho phép tính trì hoãn-cộng
      Ví dụ nếu xung nhịp PDM là 2MHz, về lý thuyết có thể trì hoãn với độ chính xác 0,5µs
      Thực tế có lẽ sẽ dùng độ chính xác thấp hơn, nhưng xung nhịp I2S thường tối đa khoảng 192kHz
      Micro PDM cũng rẻ hơn

  • Nếu tìm camera âm thanh trên YouTube, có khá nhiều màn trình diễn khá ấn tượng cho thấy hiệu năng của chúng
    Một trong những công ty tôi đã theo dõi một thời gian là đây, và có vẻ cả những hãng lớn như FLIR cũng đang tham gia: https://www.youtube.com/@gfaitechgmbh
    Một trường hợp sử dụng thú vị nhưng rợn người là ghi âm ở nơi công cộng rồi sau đó “zoom in” vào cuộc trò chuyện giữa những cá nhân cụ thể

    • Tôi rất quan tâm đến việc các mảng như vậy có thể thu nhỏ đến mức nào
      Nói chuyện với một người bạn dùng ốc tai điện tử, tôi nghĩ nếu có xử lý tín hiệu phù hợp thì có thể giúp ích rất nhiều cho việc nghe

  • Tôi muốn quay lại làm nghiên cứu sinh và thử các ứng dụng y tế bằng cách kết hợp với mảng loa siêu âm
    Về bản chất, nó giống như HIFU (siêu âm hội tụ cường độ cao) siêu mạnh có phản hồi thời gian thực
    https://en.wikipedia.org/wiki/Focused_ultrasound

    • Tôi đang làm tiến sĩ về mảng pha siêu âm trong không khí và có nói chuyện với những người phía y tế ở hội nghị hoặc phòng thí nghiệm; trong chất rắn và chất lỏng thì khó hơn rất nhiều
      Tần số cao hơn nhiều, nên không phải 40kHz mà phải nghĩ tới khoảng 1~10MHz, và các mạch điện tử thông thường về cơ bản là không dùng được
    • Một vấn đề là khi sóng âm đi qua chất rắn và chất lỏng, tốc độ âm thanh không cố định trên toàn bộ băng thông quan tâm
    • Nghiên cứu sinh FUS mà bạn đang tìm có thể là tôi
      Nếu muốn trao đổi, cứ liên hệ qua email trong hồ sơ
    • Với ứng dụng y tế, có vẻ nhiều khả năng sẽ cần ghép tiếp xúc chứ không phải truyền trong không khí

  • Tôi mong công nghệ này được đóng gói tốt và đưa vào nhiều thiết bị di động
    Tôi nghĩ một trong những lý do khiến các thứ như trợ lý, bộ dịch đa năng bị hạn chế là chất lượng âm thanh kém
    Nếu có thể giảm nhiễu và nhận biết hướng thì sẽ có tiềm năng giúp ích rất lớn
    Ví dụ, tôi muốn dịch theo thời gian thực cuộc trò chuyện nhóm quanh bàn ăn
    Trước hết, sẽ rất tốt nếu điện thoại và tai nghe có thể kết hợp các micro của từng thiết bị để dùng cho mục đích này
    Xa hơn nữa, sẽ thế nào nếu tất cả điện thoại ở gần nhau có thể hợp tác để cung cấp âm thanh định hướng chất lượng cao
    Tất nhiên là với điều kiện có thể giải quyết vấn đề quyền riêng tư

    • Với những người bị khiếm thính như tôi, việc cung cấp phụ đề thời gian thực trong môi trường ồn ào như tụ họp hoặc tiệc tùng, đồng thời tách và nhóm lời nói của các người nói khác nhau, sẽ là killer app
      Nó có thể thay đổi cuộc sống
      Live Transcribe của Android hiện rất tốt, nhưng thậm chí không cố tách xem từ nào đến từ người nói nào
    • MacBook Pro đời mới đã có nhiều micro, và có lẽ đang thực hiện kiểu xử lý giống mảng pha nào đó
    • Điều này được gọi là bài toán cocktail party
      Nó cho thấy não bộ xử lý khổng lồ đến mức nào để giúp ta hiểu được người khác đang nói gì với mình trong một căn phòng ồn ào
      https://en.wikipedia.org/wiki/Cocktail_party_effect?wprov=sf...
    • Thông thường, để tính dịch pha đúng cách, cần biết chính xác vị trí micro trong không gian, và đồng hồ của các điện thoại cũng phải được đồng bộ với độ chính xác rất cao
      Đại khái là ở mức gấp 10 lần tần số âm thanh cao nhất muốn thu, tức trong phạm vi một phần vài chục nghìn giây
      Ngoài ra, nếu vị trí các micro trong mảng không nằm trên đường thẳng, vòng tròn hoặc một hình học đơn giản khác, thì phần mã để trích xuất tín hiệu cải thiện — tức phần toán — sẽ trở nên rất khó

  • Boeing đã chế tạo phiên bản hình cầu của thiết bị như vậy và dùng nó trên nguyên mẫu 787 để tìm các ứng viên vật liệu cách âm
    Người ta nói rằng trong môi trường ồn ào như máy bay, ảo giác thính giác có thể khiến ta cảm thấy âm thanh phát ra từ nơi khác với vị trí thực tế
    Khi có ngân sách trọng lượng cố định cho vật liệu cách âm, việc đánh đúng điểm 80/20 trở nên quan trọng

  • Nếu muốn nghịch Zynq 7010, bạn nên xem bo EBAZ4205
    Có thể mua trên AliExpress với giá 20~30 euro, và nó từng là bộ điều khiển đào Bitcoin
    Một số người đã reverse engineering toàn bộ và đưa lên GitHub, cũng có cả bo chuyển để truy cập GPIO
    Nếu muốn bắt đầu với thứ ít phức tạp hơn, cũng có các FPGA Trung Quốc như bo “Sipeed” dùng GoWin FPGA
    Chúng khá dùng được và IDE cũng miễn phí

    • Chuỗi công cụ Xilinx cũng miễn phí

  • Tối qua tôi đang tìm hiểu thì đến đúng trang này
    Tôi tự hỏi có ai biết cách lắp micro trong phòng để chỉ ghi âm một khu vực cụ thể không
    Mục đích của tôi là ghi âm phía ghế sofa để xem TV cùng bạn bè online, đồng thời loại giọng của bạn bè và tiếng chương trình phát sóng khỏi âm thanh
    Có vẻ có thể làm được nếu tạo một mảng micro và dùng beam steering, nhưng tôi không tìm thấy nhiều ví dụ mã chạy thời gian thực trên GitHub

    • Nếu xem OBS hoặc VoiceMeeter, bạn sẽ biết cách các streamer định tuyến âm thanh có chọn lọc khi livestream hoặc ghi hình
      https://obsproject.com/
      https://voicemeeter.com/
    • Âm thanh phát sóng lớn và âm thanh gần từ bạn bè online sẽ phản xạ trong phòng và trên cơ thể
      Thứ bạn muốn không phải là micro hay công nghệ beamforming, mà là khử vọng, giống như mọi phần mềm họp video đều dùng
      Chỉ cần đưa âm thanh phát sóng và âm thanh của bạn bè làm đầu vào rồi áp dụng khử vọng cho từng luồng
    • Như trong bài viết, “phương pháp beamforming đơn giản nhất là trễ-và-cộng (DAS)”
      Đo khoảng cách từ một điểm, tức ghế sofa, đến từng micro; trì hoãn tín hiệu trong miền thời gian đúng bằng thời gian âm thanh đi từ ghế sofa tới micro rồi cộng chúng lại
      Về cơ bản là cố làm cho các micro như thể đã nhận tín hiệu từ ghế sofa vào cùng một thời điểm, dù chúng ở các khoảng cách khác nhau
      Để cách này có hiệu quả, cần đảm bảo chênh lệch khoảng cách giữa các micro đủ lớn